[5] 파드(Pod) -2

1. 초기화 컨테이너

초기화 컨테이너는 앱 컨테이너가 실행되기 전 파드를 초기화한다.

보안상 이유로 앱 컨테이너 이미지와 같이 두면 안 되는 앱의 소스 코드를 별도로 관리할 때 유용하다.

• 초기화 컨테이너는 여러 개를 구성할 수 있다. 여러 개 있다면 파드 템플릿에 명시한 순서대로 초기화 컨테이너가 실행된다.
• 초기화 컨테이너는 실행이 실패하면 성공할 때까지 재시작한다. 이러한 특성을 이용하면 쿠버네티스의 "선언적"이라는 특징에서 벗어날 수 있다. 즉, 필요한 명령들을 순서대로 실행하는 데 사용하는 것이다.
• 초기화 컨테이너는 모두 실행된 후 앱 컨테이너 실행이 시작된다.

이러한 특징을 이용하여 파드를 실행할 때 앱 컨테이너가 외부의 특정 조건을 만족할 때까지 기다렸다가 실행하도록 할 수 있다.

예를 들어, 초기화 컨테이너가 외부의 특정 조건을 만족할 때까지 대기하고 있다가 조건이 충족된 후 앱 컨테이너를 실행하는 것이다.

 

초기화 컨테이너는 앱 컨테이너와 비슷하게 동작하지만 몇 가지 다른 점이 있다. 특히 프로브를 지원하지 않는다. 왜냐하면 파드가 모두 준비되기 전에 실행한 후 종료되는 컨테이너이기 때문이다.

 

<초기화 컨테이너를 설정한 파드 설정 예시>

 

1. 첫 번째 초기화 컨테이너의 .spec.initContainers[ ].name 필드 값으로는 init-myservice라는 이름으로 설정했다.                          .image 필드 값으로는 위와 같은 이미지를 설정해주었고 .command 필드 값으로 해당 컨테이너를 실행할 때 2초를 대기한 후 helloworld01이라는 메시지를 출력하게 설정하였다.
2. 두 번째 초기화 컨테이너의 .spec.initContainers[ ].name 필드 값으로는 init-mydb라는 이름으로 설정하였고, .command 필드 값으로는 해당 컨테이너를 실행할 때 2초 대기한 뒤 helloworld02라는 메시지를 출력하게 설정했다.
3. .spec.containers[ ]의 하위 필드는 실제로 생성할 파드를 설정했다. .command 필드 값으로는 해당 컨테이너를 실행할 때 "The app is running!" 메시지를 출력하고 3600초 대기하도록 설정하였다.

즉, 위 코드는 kubernetes-simple-pod라는 파드를 생성하기 전 초기화 컨테이너로 init-service와 init-mydb를 실행한다.

---

2. 파드 인프라 컨테이너

쿠버네티스에는 모든 파드에서 항상 실행되는 pause라는 컨테이너가 있다. 이 pause를 "파드 인프라 컨테이너(Pod Infrastructure Container)"라고 한다.

파드 인프라 컨테이너 구조

pause는 파드 안 기본 네트워크로 설정되며, 프로세스 식별자가 1(PID 1)로 설정되므로 다른 컨테이너의 부모 컨테이너 역할을 한다.

파드 안 다른 컨테이너는 pause 컨테이너가 제공하는 네트워크를 공유해 사용한다. 그래서 파드 안 다른 컨테이너가 재시작됐을 때는 파드의 IP를 유지하지만, pause 컨테이너가 재시작되면 파드 안 모든 컨테이너도 재시작된다.

 

kublet에는 명령 옵션으로 --pod-infra-container-image 가 있다.

*pause가 아닌 다른 컨테이너를 파드 인프라 컨테이너로 지정할 때 사용한다.

---

3. 스태틱 파드

kube-apiserver를 통하지 않고 kubelet이 직접 실행하는 파드들이 있는데 이를 스태틱 파드라고 한다.

kubelet 설정의 --pod-manifest-path라는 옵션에 지정한 디렉터리에 스태틱 파드로 실행하려는 파드들을 넣어두면 kubelet이 그걸 감지해 파드로 실행한다.

 

스태틱 파드는 kubelet이 직접 관리하며 이상이 생길 시 재시작을 한다, 또한 kubelet이 실행 중인 노드에서만 실행되고 다른 노드에서는 실행되지 않는다. kube-apiserver로 파드를 조회할 수 있지만 스태틱 파드에 어떤 명령을 실행할 수는 없다.

보통 스태틱 파드는 kube-apiserver 또는 etcd와 같은 시스템 파드를 실행하는 용도로 많이 사용된다.

 

쿠버네티스에서 파드를 실행하기 위해서는 kube-apiserver가 필요한데 kube-apiserver 자체를 처음 실행하는 별도의 수단으로 스태틱 파드를 사용하는 것이다.

 

*도커 데스크톱 안 kube-apiserver의 위치 > /etc/kubernetes/manifests

---

4. 파드에 CPU와 메모리 자원 할당

마이크로서비스 아키텍처 기반으로 여러 개 작은 프로세스를 실행하면 노드 하나에 여러 개 파드를 실행하는 일이 자주 있다.

이때 자원 사용량이 많은 파드가 노드 하나에 모여 있다면 파드들의 성능이 나빠지고 전체 클러스터의 자원 사용 효율도 낮아진다.

예를 들어, 어떤 노드에는 파드가 없어서 CPU나 메모리 같은 자원이 남고, 어떤 노드에는 파드들이 많아 파드에서 사용해야 하는 CPU나 메모리가 부족한 현상이 발생할 수도 있다.

 

이러한 현상을 막기 위해 쿠버네티스는 파드를 설정할 때 파드 안 각 컨테이너가 CPU나 메모리를 얼마나 사용할 수 있을지 조건을 지정한다.

 

파드에는 CPU와 메모리를 대상으로 자원 사용량을 설정할 수 있도록 .limits와 .requests 필드를 설정했다.

자원 사용량을 설정하는 예시 yaml

• .spec.containers[ ].resources.requests 필드는 최소 자원 요구량을 나타낸다. 파드가 실행될 때 최소한 설정된 만큼의 자원 여유가 있는 노드가 있어야 파드를 그곳에 스케줄링해 실행한다. .spec.containers[ ].resources.requests에서 요구하는 여유 자원이 있는 노드가 없다면 파드는 Pending 상태로 실행되지 않고 클러스터 안에 자원 여유가 생길 때까지 대기한다.
• .spec.containers[ ].resources.limits 필드는 자원을 최대로 얼마까지 사용할 수 있는지 제한하는 설정이다. 웹 서비스를 제공하는 컨테이너가 있다고 할 때, 급격하게 트래픽이 늘어나면 자원 사용량 또한 늘어난다. 이때 이 설정이 없다면 해당 컨테이너가 노드의 모든 자원을 사용할 수 있고 그러면 같은 노드에 실행된 다른 컨테이너가 모두 영향을 받아 최악의 상황에는 클러스터 안 모든 서비스에 영향을 끼칠 수도 있다.

쿠버네티스가 파드를 스케줄링 할 때는 노드의 현재 사용량을 보는 것이 아닌 .spec.containers[ ].resources.requests와 .spec.containers[ ].resources.limits만을 확인한다.

---

5. 파드에 환경 변수 설정

컨테이너를 사용할 때 장점 중 하나는 개발 환경에서 만든 컨테이너의 환경 변수만 변경해 실제 환경에서 실행하더라도 개발 환경에서 동작하던 그대로 동작한다는 점이다.

파드 환경 변수 설정 예시 yaml

 

.spec.containers[ ]의 하위 필드를 살펴보면 .spec.containers[ ].env[ ]라는 하위 필드를 확인할 수 있다.

이 필드에는 각각 다음과 같은 뜻이 있다.

• name:  사용할 환경 변수의 이름을 설정한다.
• value: 문자열이나 숫자 형식의 값을 설정한다.
• valueFrom: 값을 직접 할당하는 것이 아닌 어딘가 다른 곳에서 참조하는 값을 설정한다.
• fieldRef: 파드의 현재 설정 내용을 값으로 설정한다는 선언이다.
• fieldPath: .fieldRef에서 어디서 값을 가져올 것인지를 지정한다. 즉, 값을 참조하려는 항목의 위치를 지정한다.
• resourceFiledRef: 컨테이너에 CPU, 메모리 사용량을 얼마나 할당했는지에 관한 정보를 가져온다.
• containerName: 환경 변수 설정을 가져올 컨테이너 이름을 설정한다.
• resource: 어떤 자원의 정보를 가져올지 설정한다.

---

6. 파드 환경 설정 내용 적용

파드는 환경 설정 내용을 템플릿 하나에 모두 작성한 후 적용해야 한다.

$ kubectl apply -f 0000.yaml

 

환경 변수 설정을 확인하기 위해서 아래 명령어를 입력 후 컨테이너 안으로 접속해 준다.

이후 env 명령어를 실행해 환경 변수를 확인한다.

KUBERNETES_ 라는 접두어를 사용하는 환경 변수들은 쿠버네티스 안에서 현재 사용 중인 자원 관련 정보가 있다.

---

7. 파드 구성 패턴

파드로 여러 개의 컨테이너를 묶어서 구성하고 실행할 때 몇 가지 패턴을 적용할 수 있다.

---

7.1. 사이드카 패턴

사이드카 패턴은 원래 사용하려던 기본 컨테이너의 기능을 확장하거나 강화하는 용도의 컨테이너를 추가하는 것이다. 기본 컨테이너는 원래 목적의 기능에만 충실하도록 구성하고, 나머지 공통 부가 기능들은 사이드카 컨테이너를 추가하여 사용한다.

사이드카 패턴 구조

 

일반적인 웹 서버라면 웹 서버 컨테이너는 웹 서버 역할만 하고 로그는 파일(파일 시스템안에)로 남긴다. 사이드카 역할인 로그 수집 컨테이너는 파일 시스템에 쌓이는 로그를 수집해서 외부의 로그 수집 시스템으로 보내는 역할을 한다.

 

이와 같이 구성을 하면 웹 서버 컨테이너를 다른 역할을 하는 컨테이너로 변경했을 때도 로그 수집 컨테이너는 그대로 사용할 수 있다.

즉, 공통 역할을 하는 컨테이너의 재사용성을 높일 수 있다.

---

7.2. 앰배서더 패턴

앰배서더 패턴은 파드 안에서 프록시 역할을 하는 컨테이너를 추가하는 패턴이다. 파드 안에서 외부 서버에 접근할 때 내부 프록시에 접근하도록 설정하고 쉽게 외부와의 연결은 프록시에서 알아서 처리한다.

 

앰배서더 패턴 구조

 

웹 서버 컨테이너는 캐시에 localhost로만 접근하고 실제 외부 캐시 중 어디로 접근할지는 프록시 컨테이너가 처리한다.

---

7.3. 어댑터 패턴

어댑터 패턴은 파드 외부로 노출되는 정보를 표준화하는 어댑터 컨테이너를 사용한다는  의미이다.

주로 어댑터 컨테이너 파드의 모니터링 지표를 표준화한 형식으로 노출시키고, 외부의 모니터링 시스템에서 해당 데이터를 주기적으로 가져가서 모니터링하는데 이용한다.

어댑터 패턴의 구조

 

 

<출처>
정원천 외 3명, 쿠버네티스 입문 90가지 예제로 배우는 컨테이너 관리 자동화 표준