Kubernetes Sidecar Container / 쿠버네티스, 사이드카, 컨테이너, 패턴, pattern

Kubernetes Sidecar Container

---

기존에 사용중인 container의 변경 없이 기능을 확장하기 위해 활용되는 것이 Sidecar container

Layer을 나눠서 기능별로 구분하여 사용하면 확장성과 재사용 측면에서 유리

이미 만들어진 container를 활용하여 추가 서비스를 붙이는 것으로, 시간 절약 / 리소스 효율화 등이 목적

독립적으로 구성 -> 확장성, 재사용에 유리한 이유

 

하나의 pod 에 배치되는 container는 pod의 정보를 공유함

즉, pod에서 내부의 container들이 volume을 공유하고, local network, host IPC를 통해 서로 통신이 가능하다는 뜻

 

주기적으로 외부에서 GIT정보를 동기화 해야하는 경우 Sidecar container를 사용할 수 있음

1. Sidecar container가 주기적으로 github에서 정보를 가져옴
2. 변경된 사항에 대하여 공유된 mount volume에 저장
3. Application container 에서 해당 정보를 사용

단계를 좀 간단하게 줄였는데, 이런식으로 활용이 가능

 

apiVersion: v1
kind: Pod
metadata:
  name: github-puller-test
spec:
  containers:      
  - name: nignx #app container
    image: nginx
    ports: 
    - containerPort: 80
    volumeMounts:
    - mountPath: /var/www/html
      name: git
  - name: puller #sidecar container
    image: [도커허브ID]/[레포지터리]:[버전]
    env:
    - name: GIT_REPO
      value: {{https://~~ html page}}
    volumeMounts:
    - mountPath: /var/lib/data
      name: git
    command:
    - "sh"
    - "-c"
    - "git clone $GIT_REPO . && watch -n 600 git pull"
  volumes:           
  - name: git
    emptyDir: {}

HTTP로 동작하는 nginx container가 있고, 해당 app에 사용되는 데이터를 동기화해주는 것

즉 기본 container와 sidecar container(보조)가 존재

두 container가 협업을 함과 동시에 서로 다른 layer를 갖고 있기 때문에 앞서 말한 장점을 챙길 수 있음

 

Kubernetes Sidecar Container

볼수 있듯이 치환성과 재사용성을 높여주고, 설정분리, 보안, 확장성, 유연성 등 많은 곳에서 장점을 가져갈 수 있음

OOP의 상속과 같은 속성에 유사하다고 볼 수 있음

하지만 Sidecar container는 추가적인 리소스 할당, health check, restart 등 관리해야할 포인트가 늘어남

따라서 별도의 Sidecar container를 사용하는게 좋을지, 병합하여 사용하는게 좋을지는 사용자의 환경에 따라 다름