1) About
어플리케이션 2개가 서로 역할과 기능이 달라서 코드 상에서 분리가 되어야 하지만, 두 기능이 함께 동작해야 하는 경우에 (즉, 각 어플리케이션의 라이프사이클을 공유하는 경우) 여러 컨테이너가 포함된 Pod를 고려해볼 수 있음
2) YAML
apiVersion: v1
kind: Pod
metadata:
name: sample-pod
labels:
name: sample-pod
spec:
containers:
- name: sample-container-1
image: sample-container-1
ports:
- containerPort: 8080
- name: sample-container-2
image: sample-container-2
YAML
복사
3) Scaling
여러 컨테이너가 한 Pod에 있을 때의 Scaling 역시 Replica Set을 이용할 수 있음
Replica Set을 이용하는 Deployment를 사용하게 되면 Scaling을 만족함과 동시에 Rolling Update 및 Rollback도 가능
4) Init Container
예를 들어 한 Pod에 A, B 컨테이너로 구성했다면, 두 컨테이너는 라이프사이클을 동일하게 유지
만일 A 컨테이너가 B 컨테이너의 커넥션을 이용하는 어플리케이션이라면, B 컨테이너가 구성되기 전까지는 FAIL이 발생할 것이고 해당 실패는 Pod의 재실행으로 이어짐
즉, 운이 좋기 B 컨테이너가 먼저 실행되고 A가 구성되면 정상적으로 Pod가 실행 상태가 됨
이 때 A, B 컨테이너 중 B 컨테이너를 먼저 실행한 뒤에 A를 실행시키고 싶다면 어떻게 해야할까?
→ Pod의 생성 옵션으로 initContainers를 기재할 수 있는데, initContainers에 기재된 컨테이너들을 순차적으로 하나씩 다 구성하는데 성공하면 containers에 기재된 컨테이너들이 구성됨
→ 만일 initContainers에서 기재된 컨테이너들의 구성에 실패하면, Pod의 재실행으로 이어짐
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
- name: init-mydb
image: busybox:1.28
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
YAML
복사
** Init Container의 자세한 내용은 아래 링크를 참고
5) Self Healing
Replica Set 및 Replication Controller에 의해 Pod가 관리되도록 구성하면, Pod로 구성된 어플리케이션들은 문제가 생겼을 때 정해진 수의 Pod를 만족시키기 위해 자체적으로 Pod를 생성하는 과정을 거치게 되면서 Self Healing을 수행