Passwd

Docker에서 컨테이너의 로그를 확인하는 방법과 비슷하게, 쿠버네티스에서도 아래와 같이 포드의 로그를 확인할 수 있다. 도커 컨테이너 로그 확인 docker logs # -f : follow. 추가되는 로그 실시간 확인 쿠버네티스 포드 로그 확인 kubectl logs # -f : follow. 추가되는 로그 실시간 확인 단, 포드 내에 여러 개의 컨테이너가 동작하고 있다면 로그를 확인할 컨테이너 이름까지 명시해야 한다. 컨테이너명을 명시하지 않으면 이름을 지정하라는 메시지가 출력되며 로그 확인을 실패한다. kubectl logs

개요 Docker는 어떠한 이유로 프로세스가 종료되면 컨테이너도 종료된다. 종료된 컨테이너는 수동으로 동작시키거나 새 컨테이너를 생성시킬 때까지 비활성상태가 유지되고, 사용자에게 서비스를 제공하지 못한다. Kubernetes는 애플리케이션이 충돌할 때마다 서비스를 복구하기 위해 컨테이너를 재시작하려고 시도한다. 재시작 횟수는 get pods 명령으로 확인할 수 있다. (RESTART 부분) kubectl get pods 컨테이너가 정상인데 애플리케이션이 동작하지 않는 상태인 경우, 쿠버네티스는 컨테이너가 정상적으로 동작하고 있기 때문에 애플리케이션도 정상적으로 동작하는 상태인 것으로 간주한다. 하지만 실제로 서비스는 사용자에게 제공되지 않는 상태이기 때문에 컨테이너를 재시작하거나, 삭제 후 새 컨테이너를..

포드 상태 1. Pending 포드가 처음 생성된 상태다. 포드 배치 여부를 파악하며, 쿠버네티스가 포드를 배치할 노드를 찾지 못하면 Pending 상태를 유지한다. 아래 명령으로 Pending 상태가 유지되는 원인을 확인할 수 있다. kubectl describe pod 2. ContainerCreating 포드가 스케쥴링되어서 이미지를 pull하고, 컨테이너를 시작하는 상태다. 3. Running 포드 내 모든 컨테이너를 시작하여 포드가 실행 중인 상태다. 프로그램이 완료되거나 종료될 때까지 상태를 유지한다. Pod 상태는 아래와 같이 get pods 명령으로 확인할 수 있다. kubectl get pods Pod Conditions TRUE/FALSE 값으로 포드의 상태를 알려주는 배열 Type S..

개요 큰 단일 애플리케이션을 마이크로서비스라는 하위 요소로 분리하는 개념은 독립적이고, 작고, 다시 사용할 수 있는 코드 집합을 개발하고 배포하는 것을 가능하게 한다. 즉, 전체 애플리케이션을 수정하는 대신 필요에 따라 각 서비스를 수정하고, 축소/확대하는 것이 가능하다. 다중 컨테이너 포드 온전한 서비스를 동작시키기 위해 여러 기능이 함께 동작해야 하는 경우, 다중 컨테이너 포드를 이용할 수 있다. 포드 내의 컨테이너는 수명주기가 같고, 같은 네트워크에 존재하기 때문에 서로를 localhost로 참조할 수 있으며, 같은 볼륨에 접근할 수 있기 때문이다. 포드 정의 파일의 spec 섹션에서 containers 섹션이 배열인 이유가 바로, 멀티컨테이너 포드를 사용할 수 있게끔 하기 위해서다. apiVers..

Node Affinity Pod에 특정 노트에서 호스팅하도록 한다. Node Selector가 제공하지 못하는 OR, Not 등의 고급 기능을 제공한다. Node Selector와 마찬가지로 node에 레이블이 설정되어 있어야 한다. 설정 방법 포드 정의 파일에 affinity 속성을 추가한다. apiVersion: v1 Kind: Pod metadata: myapp-pod spec: containers: - name: data-processor image: data-processor affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExcution: nodeSelectorTerms: - matchExpressions: - key: size op..

Node Selector 특정 노드에만 포드를 배치할 수 있도록 제한하는 방법 중 하나다. 포드 정의 파일에 nodeSelector라는 속성을 추가하여 사용한다. apiVersion: v1 kind: Pod metadata: name: myapp-pod spec: containers: - name: data-processor image: data-processor nodeSelector: type: cpu type: cpu는 포드 생성 전에 지정된 레이블로, 노드에 레이블이 지정되어 있어야 한다. 쿠버네티스 스케쥴러는 이 레이블을 이용해 포드를 배치할 노드를 식별한다. 노드에 레이블 지정 kubectl labels nodes = # 예시 kubectl labels nodes node_1 size=Larg..

Taints Node에 Pod가 배치될 수 없도록 Node에 설정한다. Tolerations Pod에 설정하며, 일치하는 Taint가 있는 Node에 스케쥴링될 수 있도록 한다. Taints와 Tolerations은 함께 동작하면서 포드가 적절하지 않은 노드에 배치되지 않도록 한다. 포드가 특정 노드에 배치되도록 설정하는 것이 아니다. 설정 방법 Taint kubectl taint nodes # 예시 kubectl taint nodes node1 app=blue:NoSchedule taint-effect는 스케쥴링된 포드에 동일한 toleration이 없는 경우 포드 처리 방식이다. taint-effect에는 아래의 세 개 값을 설정할 수 있다. NoSchedule 포드를 노드에 배치하지 않음 Prefe..

Pod는 배치된 Node의 CPU, MEM, 디스크 등의 리소스를 소비하기 때문에, 쿠버네티스 스케쥴러는 Pod에서 요구하는 리소스 양과 Node에서 사용할 수 있는 리소스 양을 고려하여 Pod를 배치한다. Pod가 배치된 Node에 리소스가 충분하지 않으면 Pod는 Pending 상태에 머무르며, 이 부분은 describe 명령어 출력 결과의 event 란에서 확인할 수 있다. Resource Requirement 컨테이너가 필요로 하는 최소 CPU/MEM 등의 리소스 쿠버네티스 스케쥴러는 이 값을 바탕으로 Pod를 배치할 수 있을 만큼 리소스가 충분한 Node를 식별한다. Pod 배포 정의 파일에 아래와 같이 정의할 수 있다. apiVersion: v1 kind: Pod metadata: name: ..

Service Account는 인증, 권한, 역할 기반 접근 제어 등과 같은 쿠버네티스의 보안 관련 개념과 관련된 개념이다. 사용자 계정; User Account 사람이 사용하는 계정이다. 관리 작업을 수행하기 위해 쿠버네티스 클러스터에 접근하는 관리자, 애플리케이션 배포를 위한 클러스터에 접근하는 개발자 등이 사용한다. 서비스 계정; Service Account 기계가 사용하는 계정으로 애플리케이션이 쿠버네티스 클러스터와 상호작용하는 데 사용한다. Service Account Token 서비스 계정 생성 시 자동으로 생성되며 외부 애플리케이션이 Kubernetes API에 인증할 때 사용한다. 생성된 토큰은 secret 개체로 저장된다. 서비스 계정 생성 -> 서비스 계정 토큰 생성 -> secret ..

도커 컨테이너에 프로세스 실행 user와 capabilities를 설정할 수 있던 것과 같이 쿠버네티스에서도 동일한 부분을 설정할 수 있다. 쿠버네티스 컨테이너는 Pod에 캡슐화되어 있으므로 컨테이너 레벨, 또는 Pod 레벨에서 설정을 구성할 수 있다. Pod 레벨 Pod 내 모든 컨테이너에 설정을 적용한다. yaml 파일에서 securityContext 옵션을 사용하여 프로세스 실행 user를 지정할 수 있다. apiVersion: v1 kind: Pod metadata: name: web-pod spec: securityContext: runAsUser: 1000 containers: - name: ubuntu image: ubuntu command: ["sleep", "3600"] Container..