[K8S] Multiple Container

같은 lifecycle 을 공유하는 Multiple container pods.
같은 Network, Storage Volume을 공유한다.

 

 

 

# command 이용해서 만들기
controlplane ~ ➜  kubectl run yellow --image=busybox --dry-run=client -o yaml > yellow.yaml
# yellow.yaml 수정 
controlplane ~ ➜ cat yellow.yaml 
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: yellow
  name: yellow
spec:
  containers:
  - image: busybox
    name: lemon
    resources: {}
    command: [ "sleep","1000" ]
  - image: redis
    name: gold
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

controlplane ~ ➜ kubectl create -f yellow.yaml 
pod/yellow created

controlplane ~ ➜  kubectl get pods
NAME        READY   STATUS    RESTARTS   AGE
app         1/1     Running   0          19m
blue        2/2     Running   0          18m
fluent-ui   1/1     Running   0          19m
red         3/3     Running   0          19m
yellow      2/2     Running   0          18s

 

[실습]

 

ElasticSearch : Data Collecting could be any metrics, logs

Kibana: Dashboard

# We have deployed an application logging stack in the elastic-stack namespace

$ kubectl get ns
NAME              STATUS   AGE
default           Active   24m
elastic-stack     Active   21m
kube-flannel      Active   24m
kube-node-lease   Active   24m
kube-public       Active   24m
kube-system       Active   24m

$ kubectl -n elastic-stack logs kibana
{"type":"log","@timestamp":"2025-01-08T10:35:25Z","tags":["status","plugin:grokdebugger@6.4.2","info"],"pid":1,"state":"green","message":"Status changed from yellow to green - Ready","prevState":"yellow","prevMsg":"Waiting for Elasticsearch"}
...
$ kubectl exec -it app -n elastic-stack -- cat /log/app.log
[2025-01-08 10:45:39,368] INFO in event-simulator: USER2 logged in
[2025-01-08 10:45:40,031] WARNING in event-simulator: USER5 Failed to Login as the account is locked due to MANY FAILED ATTEMPTS.
[2025-01-08 10:45:40,031] INFO in event-simulator: USER4 logged out
...
$ kubectl logs app -n elastic-stack

 

# Edit the pod in the elastic-stack namespace to add a sidecar container to send logs to Elastic Search. Mount the log volume to the sidecar container.
# Only add a new container. Do not modify anything else. Use the spec provided below.

# Note: State persistence concepts are discussed in detail later in this course. For now please make use of the below documentation link for updating the concerning pod.

Communicate Between Containers in the Same Pod Using a Shared Volume

 

controlplane ~ $ kubectl edit pod app -n elastic-stack
error: pods "app" is invalid
A copy of your changes has been stored to "/tmp/kubectl-edit-3107689943.yaml"
error: Edit cancelled, no valid changes were saved.


controlplane ~ $ kubectl replace --force -f /tmp/kubectl-edit-3107689943.yaml
pod "app" deleted
pod/app replaced

 

이런 식으로 대쉬보드 사용 가능

 

# Sidecar

Pod 안에 포함된 컨테이너 중 하나로, 주 컨테이너(Main Container)와 함께 실행되며 애플리케이션의 기능을 보완하거나 지원하는 역할을 수행한다.
Kubernetes의 멀티 컨테이너 Pod 설계 방식 중 가장 널리 사용되는 패턴이다.

 

주요 특징

 

• Pod 내부에서 실행:
  • Sidecar는 주 컨테이너와 동일한 Pod 안에서 실행되므로, 같은 네트워크 네임스페이스와 스토리지 볼륨을 공유.
• 보조 역할 수행:
  • 주 컨테이너의 기능을 보완하거나 확장 (예: 로깅, 데이터 동기화, 프록시, 보안 처리.)
• 독립적인 관리 가능:
  • Sidecar 컨테이너는 주 컨테이너와 독립적으로 개발, 배포, 업데이트 가능

Sidecar 사용 사례

(1) 로그 수집

• 애플리케이션 로그를 처리하고 중앙 로그 시스템으로 전달.
• 예시: 주 컨테이너의 로그를 Fluentd 또는 Logstash가 수집하여 전송.

(2) 프록시 (Proxy)

• 주 컨테이너로의 트래픽을 관리하거나 모니터링.
• 예시: Envoy 또는 Istio 같은 서비스 메쉬 프록시로 네트워크 트래픽 제어.

(3) 데이터 동기화

• 외부 소스와 데이터를 동기화하거나 애플리케이션에 필요한 설정 제공.
• 예시: 구성 파일이나 인증 키를 주기적으로 업데이트.

(4) 인증 및 보안

• 주 컨테이너에 인증 토큰 제공 또는 암호화/복호화 처리.
• 예시: 주 컨테이너의 요청을 보안 측면에서 필터링하거나 토큰을 주입.

(5) 데이터 캐싱

• 주 컨테이너의 데이터 요청을 캐싱하여 성능을 향상.
• 예시: Redis 컨테이너가 캐시 역할 수행.

(6) 메시 처리

• 주 컨테이너와 메시 큐 간 데이터를 관리.
• 예시: RabbitMQ, Kafka 등의 메시 브로커와 통신.

패턴 예시

apiVersion: v1
kind: Pod
metadata:
  name: sidecar-example
spec:
  containers:
    # Main Container
    - name: main-app
      image: nginx
      volumeMounts:
        - name: shared-logs  # 두 컨테이너가 같은 파일 시스템(EmptyDir)을 사용
          mountPath: /var/log/app
    # Sidecar Container - 로그를 읽어와 중앙화된 로그 시스템으로 전송
    - name: log-collector
      image: fluentd
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/app
  volumes:
    - name: shared-logs
      emptyDir: {}

 

Sidecar와 Init Container의 차이

	Sidecar Container	Init Container
역할	주 컨테이너의 기능 보완 및 확장	주 컨테이너 실행 전 초기화 작업 수행
실행 시점	Pod의 라이프사이클 동안 동작	주 컨테이너 실행 전에만 동작
중단 시 영향	주 컨테이너에 실시간으로 영향을 미칠 수 있음	Pod 상태에 따라 재시작 가능
사용 사례	로그 수집, 데이터 캐싱, 보안 인증	설정 파일 다운로드, DB 마이그레이션 등