목차
5.1 파드 개념
•
쿠버네티스는 ‘파드’라는 단위로 컨테이너를 묶어 관리 → 여러 개의 컨테이너로 구성된다.
•
컨테이너마다 역할 부여 가능하다.
◦
ex) 컨테이너 3개 → 역할: 웹 서버, 로그 수집기, 볼륨 컨테이너
▪
컨테이너들은 IP 하나를 공유
▪
외부에서 해당 파드에 접근 시 IP를 사용하고, 파드 안 컨테이너와 통신할 때는 컨테이너마다 다르게 설정한 포트를 사용한다.
5.2 파드 사용하기
# pod-sample.yaml : 메시지를 출력하는 컨테이너를 포함하는 파드 설정
apiVersion: v1
kind: Pod
metadata:
name: kubernetes-simple-pod
labels:
app: kubernetes-simple-pod
spec:
containers:
- name: kubernetes-simple-pod
image: arisu1000/simple-container-app:latest
ports:
- containerPort: 8080
YAML
복사
pod/pod-sample.yaml
•
.metadata.name: 파드 이름 설정
•
.metadata.labels.app: 오브젝트를 식별하는 레이블 설정
•
.spec.containers[].name: 컨테이너의 이름 설정
◦
- : 하위 필드를 배열 형태로 묶겠다는 뜻
•
.spec.containers[].image: 컨테이너에서 사용할 이미지를 정한다.
•
.spec.containers[].ports[].containerPort: 해당 컨테이너에 접속할 포트 번호를 설정한다.
kubectl apply -f pod-sample.yaml 로 클러스터 적용
kubectl get pods 로 파드 조회
5.3 파드 생명주기
파드는 생성부터 삭제까지의 과정에 생명 주기(lifecycle)가 있다.
상태 | 설명 |
Pending | 쿠버네티스 시스템에 파드를 생성하는 중임을 뜻한다 |
Running | 파드 안 모든 컨테이너가 실행 중인 상태 |
Succeeded | - 파드 안 모든 컨테이너가 정상 실행 종료된 상태
- 재시작되지 않는다 |
Failed | - 파드 안 컨테이너 중 정상적으로 실행 종료되지 않은 컨테이너가 있는 상태
- 컨테이너 종료 코드가 0이 아니면 비정상 종료이거나 시스템이 직접 컨테이너를 종료한 것 |
Unknown | 파드의 상태를 확인할 수 없는 상태 |
kubectl describe pods <파드 이름> 명령으로 파드의 세부 정보를 알 수 있다.
STATUS 항목이 파드의 생명 주기이다.
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
YAML
복사
Conditions 항목은 파드의 현재 상태 정보를 나타내며, Type과 Status로 구분되어 있다.
•
Type
상태 | 설명 |
Initialized | 모든 초기화 컨테이너가 성공적으로 시작 완료되었다는 뜻 |
Ready | 파드는 요청들을 실행할 수 있고 연결된 모든 서비스의 로드밸런싱 풀에 추가되어야 한다는 뜻 |
ContainersReady | 파드 안 모든 컨테이너가 준비 상태라는 뜻 |
PodScheduled | 파드가 하나의 노드로 스케줄을 완료했다는 뜻 |
Unschedulable | 스케줄러가 자원의 부족이나 다른 제약 등으로 지금 당장 파드를 스케줄할 수 없다는 뜻 |
◦
Status
▪
True(상태 활성화), False(상태 비활성화), Unknown(상태 알 수 없음)
kubectl delete pod <파드 이름> 명령으로 파드를 삭제한다.
5.4 kubelet으로 컨테이너 진단하기
•
컨테이너 실행 후 kubelet이 컨테이너를 주기적으로 진단 → ‘프로브(Probe)’가 필요하다.
1.
livenessProbe
•
컨테이너가 실행됐는지 확인
•
진단 실패 시 컨테이너를 종료시키고, 재시작
•
명시되지 않았다면 기본 상태 값은 Success
2.
readinessProbe
•
실제로 서비스 요청에 응답할 수 있는지 진단
•
진단 실패 시 엔드포인트 컨트롤러는 해당 파드에 연결된 모든 서비스를 대상으로 엔드포인트 정보를 제거한다.
•
첫 번째 readinessProbe를 하기 전까지의 기본 상태 값은 Failure
3.
startupProbe
•
컨테이너 안 애플리케이션이 시작되었는지 나타낸다.
•
진단이 성공할때까지 다른 나머지 프로브는 활성화되지 않으며, 진단이 실패하면 kubelet이 컨테이너를 종료시키고, 재시작 정책에 따라 처리한다.
•
startupProbe가 없다면 기본 상태 값은 Success
5.4.1 프로브의 장점
•
프로브가 있는 것이 쿠버네티스의 장점
•
readinessProbe를 지원하는 컨테이너라면 실제 트래픽을 받을 준비가 되었음을 확인한 후 트래픽을 받기 때문에 프로세스가 시작된 후 앱이 초기화될 때까지 시간이 걸리는 상황에 유용하다.
•
앱 실행 시 대용량 데이터를 불러와야 하거나, 컨테이너 실행은 시작됐지만 앱의 환경 설정 실수로 앱이 실행되지 않는 상황 등에 대비할 수 있다.
5.5 초기화 컨테이너
•
앱 컨테이너가 실행되기 전 파드를 초기화한다.
•
보안상 이유로 앱 컨테이너 이미지와 같이 두면 안 되는 앱의 소스 코드를 별도로 관리할 때 유용하다.
•
여러 개 구성 가능 : 파드 템플릿에 명시한 순서대로 실행된다.
•
실행 실패 시 성공할 때까지 재시작한다. → 쿠버네티스의 ‘선언적’이라는 특징에서 벗어날 수 있다. → 필요한 명령들을 순서대로 실행하는 데 사용하는 것
•
모두 실행된 후 앱 컨테이너가 실행된다.
•
파드가 모두 준비되기 전에 실행한 후 종료되는 컨테이너이기 때문에, 앱 컨테이너와 달리 readinessProbe를 지원하지 않는다.
⇒ 파드 실행 시 앱 컨테이너가 외부의 특정 조건을 만족할 때까지 기다렸다가 실행하도록 만들 수 있다.
apiVersion: v1
kind: Pod
metadata:
name: kubernetes-simple-pod
labels:
app: kubernetes-simple-pod
spec:
initContainers:
- name: init-myservice
image: arisu1000/simple-container-app:latest
command: ['sh', '-c', 'sleep 2; echo helloworld01;']
# 해당 컨테이너를 실행할 때 2초 대기한 후 helloworld01라는 메시지를 출력하라고 설정함
- name: init-mydb
image: arisu1000/simple-container-app:latest
command: ['sh', '-c', 'sleep 2; echo helloworld02;']
containers:
- name: kubernetes-simple-pod
image: arisu1000/simple-container-app:latest
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
YAML
복사
•
.spec.initContainers[]의 하위 필드에서 초기화 컨테이너 설정
•
kubernates-simple-pod라는 파드를 생성하기 전 초기화 컨테이너로 init-service와 init-mydb를 실행함
5.6 파드 인프라 컨테이너
•
모든 파드에서 항상 실행되는 pause라는 컨테이너가 있다. → 파드 인프라 컨테이너
•
pause는 파드 안 기본 네트워크로 실행되며, 프로세스 식별자가 1(PID 1)로 설정되므로
다른 컨테이너의 부모 컨테이너 역할을 한다.
•
파드 안 다른 컨테이너는 pause 컨테이너가 제공하는 네트워크를 공유해서 사용한다.
⇒ pause 컨테이너가 재시작되면 파드 안 모든 컨테이너도 재시작
5.7 스태틱 파드
•
kube-apiserver를 통하지 않고 kubelet으로 직접 실행하는 파드들 → 스태틱 파드
•
—pod-manifest-path라는 옵션에 지정한 디렉터리에 스태틱 파드로 실행하려는 파드들을 넣어두면 kubelet이 감지해 파드로 실행한다.
•
kube-apiserver나 etcd 같은 시스템 파드를 실행하는 용도로 많이 사용한다.
•
스태틱 파드 경로 : /etc/kubernetes/manifests
→ 도커 데스크톱의 리눅스 가상 머신 안에 접속해 확인 가능
◦
쿠버네티스 시스템용 파드들의 템플릿 파일들 확인 가능
screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty
# 위 명령어 실행시 No such file or directory 뜨면 아래 명령어 실행
docker run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh
cd /etc/kubernetes/manifests/
ls -alF
vi kube-apiserver.yaml # kube-apiserver.yaml 내용 수정
Shell
복사
•
env 필드를 이용해 컨테이너 환경 변수 추가
⇒ kubelet이 kube-apiserver.yaml이 변경된 것을 감지하고 재시작
kubectl describe pods kube-apiserver-docker-desktop -n kube-system | grep TEST 명령으로 환경 변수가 추가된 것을 확인할 수 있다.
kubectl edit pods kube-apiserver-docker-desktop -n kube-system 명령으로 앞에서 만든 환경변수를 삭제 후 저장한다.
→ 오류가 발생하는 것을 확인할 수 있다. kube-apiserver-docker-desktop 파드는 스태틱 파드이므로 kube-apiserver의 기능을 이용하는 edit 명령으로 수정할 수 없기 때문이다.
5.8 파드에 CPU와 메모리 자원 할당
파드 설정 시 파드 안 각 컨테이너가 CPU나 메모리를 얼마나 사용할 수 있을지 조건 지정 가능
•
.limits, .requests 필드 사용
◦
.spec.containers[].resources.limits.cpu
◦
.spec.containers[].resources.limits.memory
◦
.spec.containers[].resources.requests.cpu
◦
.spec.containers[].resources.requests.memory
CPU와 메모리 자원 할당
•
.requests : 최소 자원 요구량
•
.limits : 최대 사용량 제한
apiVersion: v1
kind: Pod
metadata:
name: kubernetes-simple-pod
labels:
app: kubernetes-simple-pod
spec:
containers:
- name: kubernetes-simple-pod
image: arisu1000/simple-container-app:latest
resources:
requests:
cpu: 0.1
memory: 200M
limits:
cpu: 0.5
memory: 1G
ports:
- containerPort: 8080
YAML
복사
pod/pod-resource.yam
5.9 파드에 환경변수 설정하기
컨테이너 사용 시 장점 중 하나가 개발 환경에서 만든 컨테이너의 환경 변수만 변경해 실제 환경에서 그대로 동작시킬 수 있다는 점이다.
apiVersion: v1
kind: Pod
metadata:
name: kubernetes-simple-pod
labels:
app: kubernetes-simple-pod
spce:
containers:
- name: kubernetes-simple-pod
image: arisu1000/simple-container-app:latest
ports:
- containerPort: 8080
env:
- name: TESTENV01
value: "testvalue01"
- name: HOSTNAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: CPU_REQUEST
valueFrom:
resourceFieldRef:
containerName: kubernetes-simple-pod
resource; requests.cpu
- name: CPU_LIMIT
valueFrom:
resourceFieldRef:
containerName: kubernetes-simple-pod
resource; limits.cpu
YAML
복사
pod/pod-env.yaml
•
name : 사용할 환경 변수 이름 설정
•
value : 문자열 / 숫자 형식 값 설정
•
valueFrom : 값을 직접 할당하는 것이 아니라, 어딘가 다른 곳에서 참조하는 값을 설정
◦
fieldRef : 파드의 현재 설정 내용을 값으로 설정한다는 선언
▪
fieldPath : .fieldRef에서 어디서 값을 가져올 것인지 지정 → 값을 참조하려는 항목의 위치
◦
resourceFieldRef : 컨테이너에 CPU, 메모리 사용량을 얼마나 할당했는지에 대한 정보 가져온다
▪
containerName : 환경 변수 설정을 가져올 컨테이너 이름을 설정
▪
resource : 어떤 자원의 정보를 가져올지 설정
5.10 파드 환경 설정 내용 적용하기
apiVersion: v1
kind: Pod
metadata:
name: kubernetes-simple-pod
labels:
app: kubernetes-simple-pod
spec:
initContainers:
- name: init-myservice
image: arisu1000/simple-container-app:latest
command: ['sh', '-c', 'sleep 2; echo helloworld01;']
- name: init-mydb
image: arisu1000/simple-container-app:latest
command: ['sh', '-c', 'sleep 2; echo helloworld02;']
containers:
- name: kubernetes-simple-pod
image: arisu1000/simple-container-app:latest
resources:
requests:
cpu: 0.1
memory: 200M
limits:
cpu: 0.5
memory: 1G
ports:
- containerPort: 8080
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
env:
- name: TESTENV01
value: "testvalue01" # 첫 번째 환경 변수
- name: HOSTNAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName # 두 번째 환경 변수
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name # 세 번째 환경 변수
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP # 네 번째 환경 변수
- name: CPU_REQUEST
valueFrom:
resourceFieldRef:
containerName: kubernetes-simple-pod
resource: requests.cpu # 다섯 번째 환경 변수
- name: CPU_LIMIT
valueFrom:
resourceFieldRef:
containerName: kubernetes-simple-pod
resource: limits.cpu # 여섯 번째 환경 변수
YAML
복사
pod/pod-all.yaml
•
환경 설정 내용을 템플릿 하나에 모두 작성한 후 적용해야 함
◦
kubectl apply -f pod-all.yaml 으로 클러스터에 적용
◦
kubectl get pods kubernetes-simple-pod 으로 조회.
•
컨테이너 안으로 접속해 제대로 환경 변수가 설정됐는지 확인
◦
kubectl exec -it kubernetes-simple-pod sh 명령.
5.11 파드 구성 패턴
구글에서 단일 노드에서 여러 개 컨테이너를 구성할 때의 패턴들 공개
5.11.1 사이드카 패턴
•
원래 사용하려던 기본 컨테이너의 기능을 확장하거나 강화하는 용도의 컨테이너를 추가하는 것
•
기본 컨테이너는 원래 목적의 기능에만 충실하도록 구성하고, 나머지 공통 부가 기능들은 사이드카 컨테이너를 추가해 사용
⇒ 컨테이너의 재사용성을 높일 수 있다.
•
웹 서버 컨테이너를 다른 역할 컨테이너로 변경했을 때도 로그 수집 컨테이너는 그대로 사용 가능
5.11.2 앰버서더 패턴
•
파드 안에서 프록시 역할을 하는 컨테이너를 추가하는 패턴
•
파드 안에서 외부 서버 접근 시 내부 프록시에 접근하도록 설정하고 실제 외부와의 연결은 프록시에서 알아서 처리한다.
•
웹 서버 컨테이너는 캐시에 localhost로만 접근하고 실제 외부 캐시 중 어디로 접근할지도 프록시 컨테이너가 처리한다.
5.11.3 어댑터 패턴
•
파드 외부로 노출되는 정보를 표준화하는 어댑터 컨테이너를 사용
•
주로 어댑터 컨테이너로 파드의 모니터링 지표를 표준화한 형식으로 노출시키고, 외부의 모니터링 시스템에서 해당 데이터를 주기적으로 가져와 모니터링하는데 이용한다.