kubectl

파드 내에 초기화만을 담당하는 컨테이너를 설정할 수도 있다. 그러면 초기화만을 수행하는 컨테이너와 요청을 처리하는 컨테이너를 별도로 개발하여 각각 재사용할 수 있다. 예를 들어 스토리지를 마운트할 때 '스토리지 안에 새로운 디럭터리를 만들고, 소유자를 변경한 후 데이터를 저장'하는 것과 같은 초기화 처리를 전담할 수 있다. Init-sample.yml apiVersion: v1 kind: Pod metadata: name: init-sample spec: containers: - name: main # 메인 컨테이너 image: ubuntu command: ["/bin/sh"] args: ["-c", "tail -f /dev/null"] volumeMounts: - mountPath: /docs # 마운..

매니페스트란 쿠버네티스의 오브젝트를 생성하기 위한 메타 정보를 YAML이나 JSON으로 기술한 파일이다. 실제 파드를 단독으로 기동하는 매니페스트를 작성하는 경우는 많지 않다. 보통 컨트롤러에 대한 매니페스트를 작성하는데 이때 파드에 대한 정보를 기술하는 부분이 포함된다. 이를 파드 템플릿이라고 하며, 파드의 매니페스트와 같다. 따라서 파드의 매니페스트를 기술하는 방법을 알고 있으면 컨트롤러를 사용할 때 도움이 된다. Nginx 컨테이너를 실행하는 매니페스트를 작성해보자. 주로 YAML파일이 JSON 파일보다 가독성이 좋아 많이 사용한다. 그리고 매니페스트를 작성할 때는 API 래퍼런스를 참고하는 것이 좋다. apiVersion: v1 kind: Pod metadata: name: nginx spen: ..

앞서 디플로이먼트 컨트롤러(Deployment Controller)에 의한 파드(Pod) 실행 예제에서 hello-world 컨테이너는 단발성 형태의 워크로드였다. 이에 적합한 쿠버네티스의 컨트롤러로 잡 컨트롤러(Job Controller)가 있다. kubectl 옵션으로 --restart=OnFailure를 지정하면 잡 컨트롤러의 제어하에 파드가 가동된다. 잡 컨트롤러는 파드가 비정상 종료하면 재시작하며 파드가 정상 종료될 때까지 지정한 횟수만큼 재실행한다. 디플로이먼트 컨트롤러를 만들 때와 마찬가지로 kubectl run 명령어 대신 kubectl create job 명령어를 사용해야 한다. 잡 컨트롤러는 컨테이너의 프로세스 종료 코드 값으로 성공과 실패를 판정하는데 , 그럼 job 2개를 생성해 하..

kubectl run에 옵션을 지정하면 파드를 디플로이먼트 컨트롤러 제어 하에 실행하는 것이 가능하다. 파드가 정지되었을 때 재기동시킬 필요가 있는지에 따라 옵션을 주면 된다. 이때 사용하는 옵션이 --restart=Always다. 반대로 파드만 독립적으로 실행하고 싶을 때는 --restart=Never 옵션을 주면 된다. --restart 옵션을 생략하면 기본값으로 Always로 실행된다. 즉 기본 적으로 디플로이먼트 컨트롤러에 의해 파드가 기동 된다. 디플로이먼트 컨트롤러 제어 하에 실행하는 방법은 아래와 같다. kubectl에 run은 서브 커맨드의 기능이 지나치게 방대해지는 것을 막기 위해 파드 자체를 만들 때만 run을 사용하고 디플로이먼트를 만들 때는 kubectl create deployme..

컨트롤러에 의한 파드 실행 kubectl run에 옵션을 지정하면 파드를 디플로이먼트 컨트롤러의 제어하에 실행하는하려면 옵션 --restart=Always을 주면된다.(기본값 Always) 파드만 독립적으로 실행하고 싶을 때는 --restart=Never 옵션을 주면된다. 파드가 정지되었을 때 재기동 시킬 필요가 있는지에 따라 옵션을 정하면 되겠다. 디플로이먼트 컨트롤러에 의해 파드가 기동될때는 백그라운드로 실행되기 때문에 -it 옵션은 무시된다. kubectl run 서브 커맨드의 기능이 지나치게 방대해지는 것을 막기 위해 파드 자체를 만들때만 run을 사용하는 것이 추천되고 있다. 디플로이먼트를 먼들 때는 kubectl create deployment --image hello-world hello-w..

윈도우를 사용한다면 전 블로그글을 확인하고 실행 환경을 구축해야한다. 파드 실행 kubectl run 명령어를 입력하고 결과가 표시될 때까지의 흐름은 다음과 같으며 도커 명령어와 비슷하다. kubectl이 쿠버네티스에게 명령을 전달한다. 노드에 이미지가 없으면 원격 리포지터리(Docker Hub)에서 다운로드 한다. 노드의 containerd가 컨테이너를 실행한다. kubectl이 터미널에 메시지를 표시한다. 쿠버네티스의 특징 중 하나는 개인의 PC, 퍼플릭 클라우드, 온프레미스의 모든 환경에서 동인할 kubectl 명령어로 조작할 수 있다는 점이다. 따라서, 미니쿠베를 잘 익혀두면 5,000대 규모의 클러스터(버전 1.11 기준)도 다룰 수 있다. 파드는 쿠버네티스에서 컨테이너를 실행하는 최소 단위이다..

쿠버네티스를 윈도우 환경에서 하나하나 정리하며 설치해보겠다. MacOS 환경에서 설치는 블로그글에서 확인할 수 있다. 아래 블로그 글에서 도커 툴박스를 설치한다. [Docker] 윈도우에서 도커 설치하기 (툴박스 vs 데스크탑) 0. 왜 툴박스를 사용해야 할까? 도커 데스크탑 애플리케이션은 윈도우 professional, enterprise, education 버전에서 사용이 가능하다. 윈도우 홈 버전은 Hyper-V를 지원하지 않아서 도커 툴박스를 사용해야 jinyes-tistory.tistory.com Docker Quickstart Terminal을 실행하면 E_FAIL (0x80004005) 에러가 날 수 있는데 그럴땐 CMD를 관리자로 열어 bcdedit /set hypervisorlauncht..

kubectl 커맨드의 기본 쿠버네티스 클러스터에게 명령을 내릴 때는 kubectl을 사용한다. kubectl 커먼대의 기본 구조는 아래와 같이 세 부분으로 구성된다. kubectl [이름] [3. 옵션] 커맨드로 동작을 지정하고 리소스 타입과 이름으로 대상이 되는 오브젝트를 지정한 뒤 옵션을 지정 1. 커맨드 get 지정한 오브젝트의 목록을 한 줄에 하나씩 출력 kubectl get -f kubectl get kubectl get kubectl get describe get 보다 자세한 정보를 출력 kubectl describe -f kubectl describe kubectl describe kubectl describe apply 매니페스트에 기술된 오브젝트가 존재하지 않으면 생성하고, 존재하면 변..

파드의 라이프 사이클 쿠버네티스의 트러블 슈팅 중 가장 많이 발생하는 것이 파드의 기동 실패 원인 분석이다. 개인의 개발 환경에서 컨테이너 이미지를 빌드하고 쿠버네티스 환경에 배포했을 때 제일 먼저 경험하는 것이 컨테이너가 기동하지 않거나 재시작을 반복하는 현상이다. 파드의 상태가 가지는 의미를 이해하고 적절한 대처를 할 수 있어야 문제를 해결할 수 있다. 문제를 파악하기 위해서는 kubectl get pods 명령어를 실행 해 나타나는 STATUS 열의 정보가 중요하다. 이 필드의 정보는 Kubernetes API를 통해 획득하는데, 이 API를 통해서 얻을 수 있는 다양한 정보 중에서 도움이 될 만한 정보가 선별되어 STATUS 열에 표시된다. STATUS 의미와 대책 ContainerCreating..

쿠버네티스의 아키텍처 및 구성요소 쿠버네티스는 마스터와 노드로 구성된다. 쿠버네티스 클러스터를 구성하는 코어 프로세스(컨테이너) kubectl K8s 클러스터를 조작하기 위한 도구로 가장 비번하게 이용되는 커맨드 라인 인터페이스다. kube-apiserver kubectl 등의 API 클라이언트로부터 오는 REST 요청을 검증하고, API 오브젝트를 구성하고 상태를 보고한다. kube-scheduler 쿠버네티스의 기본 스케줄러이며, 새로 생성된 모든 파드에 대해 실행할 최적의 노드를 선택한다. 스케줄러는 파드가 실행 가능한 노드를 찾은 다음 점수를 계산하여 가장 높은 노드를 선택한다. kube-controller-manager 컨트롤러를 구동하는 마스터상의 컴포넌트 cloud-controller-man..