사이드카 컨테이너 도입하기

사이드카 컨테이너 도입하기 (Adopting Sidecar Containers)

이 섹션은 워크로드에 새 내장 사이드카 컨테이너 기능을 도입하는 사람들에게 관련된 내용이에요.

사이드카 컨테이너는 블로그 포스트에 게시된 대로 새로운 개념이 아니에요. Kubernetes는 파드에서 여러 컨테이너를 실행해 이 개념을 구현하는 것을 허용해요. 다만 사이드카 컨테이너를 일반 컨테이너로 실행하는 것은 많은 제한이 있으며, 이는 새 내장 사이드카 컨테이너 지원으로 해결되고 있어요.

출처: 문서

본문

목표 (Objectives)

  • 사이드카 컨테이너의 필요성 이해하기
  • 사이드카 컨테이너의 문제를 문제 해결할 수 있기
  • 사이드카 컨테이너를 어떤 워크로드에나 "주입(inject)"하는 옵션 이해하기

시작하기 전에

Kubernetes 클러스터가 있어야 하고 kubectl 명령줄 도구가 클러스터와 통신하도록 구성되어 있어야 해요. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 최소 두 개 있는 클러스터에서 실행하는 것을 권장해요. 아직 클러스터가 없다면 minikube를 이용해 만들거나, 아래 Kubernetes 플레이그라운드 중 하나를 사용할 수 있어요.

버전을 확인하려면 kubectl version을 입력해요.

사이드카 컨테이너 개요

사이드카 컨테이너는 같은 파드 안에서 메인 애플리케이션 컨테이너와 함께 실행되는 보조 컨테이너예요. 이 컨테이너들은 메인 애플리케이션 코드를 직접 변경하지 않으면서 로깅, 모니터링, 보안, 데이터 동기화 같은 추가 서비스나 기능을 제공해 기본 애플리케이션 컨테이너의 기능을 강화하거나 확장하는 데 사용돼요. 사이드카 컨테이너 개념 페이지에서 더 읽을 수 있어요.

사이드카 컨테이너 개념은 새롭지 않으며 이 개념의 구현이 여러 개 있어요. 파드를 정의하는 사용자가 실행하고 싶어 하는 사이드카 컨테이너 외에도, 일부 애드온이 파드가 실행되기 전에 파드를 수정해 추가 사이드카 컨테이너가 있게 하는 것을 볼 수도 있어요. 이런 추가 사이드카를 주입하는 메커니즘은 종종 mutating webhooks이에요. 예를 들어 서비스 메시 애드온이 서로 다른 파드 사이의 상호 TLS와 전송 중 암호화를 구성하는 사이드카를 주입할 수 있어요.

사이드카 컨테이너 개념은 새롭지 않지만, Kubernetes에서 이 기능의 네이티브 구현은 새로운 것이에요. 그리고 다른 모든 새 기능과 마찬가지로 이 기능을 도입하면 특정 과제가 생길 수 있어요.

이 튜토리얼은 최종 사용자와 사이드카 컨테이너 작성자 모두가 경험할 수 있는 과제와 해결책을 탐구해요.

내장 사이드카 컨테이너의 이점

Kubernetes의 사이드카 컨테이너 네이티브 지원을 사용하면 여러 이점이 있어요.

  • 네이티브 사이드카 컨테이너를 init 컨테이너보다 먼저 시작하도록 구성할 수 있어요.
  • 내장 사이드카 컨테이너는 마지막에 종료되도록 보장되게 작성할 수 있어요. 모든 일반 컨테이너가 완료되고 종료되면 사이드카 컨테이너는 SIGTERM 신호로 종료돼요. 사이드카 컨테이너가 정상적으로 종료되지 않으면 SIGKILL 신호로 종료돼요.
  • Job에서 파드의 restartPolicy: OnFailure 또는 restartPolicy: Never일 때, 네이티브 사이드카 컨테이너는 파드 완료를 막지 않아요. 레거시 사이드카 컨테이너에서는 이 상황을 처리하는 데 특별한 주의가 필요해요.
  • 또한 Job에서 내장 사이드카 컨테이너는 완료된 후 계속 재시작되는데, 파드의 restartPolicy: Never일 때 일반 컨테이너는 그러지 않아요.

init 컨테이너와의 차이를 참고해 더 배울 수 있어요.

내장 사이드카 컨테이너 도입

SidecarContainers 기능 게이트는 Kubernetes 1.29 버전부터 베타 상태이며 기본적으로 활성화돼 있어요. 일부 클러스터는 이 기능이 비활성화되어 있거나 기능과 호환되지 않는 소프트웨어가 설치되어 있을 수 있어요.

이런 경우 파드가 거부되거나 사이드카 컨테이너가 파드 시작을 막아 파드를 쓸모없게 만들 수 있어요. 이 상태는 파드가 초기화에서 멈추는 것으로 쉽게 감지돼요. 하지만 무엇이 문제를 일으켰는지는 종종 불분명해요.

다음은 워크로드에 사이드카 컨테이너를 도입하는 동안 취할 수 있는 고려 사항과 문제 해결 단계예요.

기능 게이트 활성화 확인

가장 첫 번째 단계로, API 서버와 노드가 모두 Kubernetes v1.29 이상인지 확인해요. 노드가 이전 버전(기능이 활성화되지 않은)으로 실행되는 클러스터에서는 기능이 깨질 거예요. 컨트롤 플레인 안의 API 서버와 모든 노드에 대해 기능 게이트가 활성화되어 있는지 확인해야 해요.

기능 게이트 활성화를 확인하는 한 가지 방법은 다음과 같은 명령을 실행하는 것이에요.

  • API 서버용
  • 개별 노드용
  • 다음과 같은 것을 보게 된다면:
kubernetes_feature_enabled{name="SidecarContainers",stage="BETA"} 1

기능이 활성화되었다는 뜻이에요.

서드파티 도구와 mutating webhooks 확인

기능을 검증할 때 문제가 발생하면, 서드파티 도구나 mutating webhook 중 하나가 깨졌다는 신호일 수 있어요.

SidecarContainers 기능 게이트가 활성화되면 파드는 API에 새 필드를 얻어요. 일부 도구나 mutating webhook은 더 이른 버전의 Kubernetes API로 빌드되었을 수 있어요.

도구가 다양한 패치 전략을 사용해 파드 객체를 변형할 때 알 수 없는 필드를 그대로 전달한다면 문제가 되지 않아요. 하지만 알 수 없는 필드를 제거하는 도구가 있다면, 그것들은 v1.28+ 버전의 Kubernetes API 클라이언트 코드로 다시 컴파일되어야 해요.

이것을 확인하는 방법은 mutating admission을 통과한 파드로 kubectl describe pod 명령을 사용하는 것이에요. 어떤 도구가 새 필드(restartPolicy:Always)를 제거했다면, 명령 출력에서 그것을 보지 못할 거예요.

이런 문제가 발생하면, 도구나 webhook의 작성자에게 전체 객체 업데이트 대신 객체 수정을 위한 패치 전략 중 하나를 사용하도록 조언해 주세요.

사이드카 자동 주입

사이드카를 자동으로 주입하는 소프트웨어를 사용한다면, 네이티브 사이드카 컨테이너를 사용할 수 있게 하기 위해 따를 수 있는 몇 가지 전략이 있어요. 모든 전략은 일반적으로 사이드카가 주입될 파드가 그 기능을 지원하는 노드에 도착할지 여부를 결정하도록 선택할 수 있는 옵션이에요.

예를 들어 Istio 커뮤니티의 이 대화를 따라갈 수 있어요. 그 토론은 아래 나열된 옵션들을 탐구해요.

  • 사이드카를 지원하는 노드에 도착하는 파드 표시하기: 노드 라벨과 노드 어피니티를 사용해 사이드카 컨테이너를 지원하는 노드와 그 노드에 도착하는 파드를 표시할 수 있어요.
  • 주입 시 노드 호환성 확인: 사이드카 주입 중 다음 전략을 사용해 노드 호환성을 확인할 수 있어요. 노드 버전을 조회하고 v1.29+ 버전에서 기능 게이트가 활성화되어 있다고 가정하기, 노드 Prometheus 메트릭을 조회해 기능 활성화 상태 확인하기, 노드가 API 서버의 지원되는 버전 스큐로 실행된다고 가정하기. 노드 호환성을 감지하는 다른 사용자 지정 방법이 있을 수도 있어요.
  • 범용 사이드카 주입기 개발: 범용 사이드카 주입기의 아이디어는 사이드카 컨테이너를 일반 컨테이너뿐 아니라 네이티브 사이드카 컨테이너로도 주입하는 것이에요. 그리고 어느 것이 동작할지 결정하는 런타임 로직을 두는 거죠. 범용 사이드카 주입기는 요청을 두 번 계산하므로 낭비적이지만, 특별한 경우에는 동작 가능한 솔루션으로 간주될 수 있어요. 한 가지 방법은 네이티브 사이드카 컨테이너 시작 시 노드 버전을 감지하고, 버전이 사이드카 기능을 지원하지 않으면 즉시 종료하는 것이에요. 런타임 기능 감지 설계를 고려해볼게요: 컨테이너들이 서로 통신할 수 있도록 빈 디렉터리를 정의한다. NativeSidecar라고 부르는, restartPolicy=Always인 init 컨테이너를 주입한다. NativeSidecar는 첫 실행을 나타내는 파일을 빈 디렉터리에 쓰고 exit code 0으로 즉시 종료해야 한다. NativeSidecar는 (네이티브 사이드카가 지원될 때) 재시작 시 그 파일이 이미 빈 디렉터리에 존재하는지 확인하고, 그것을 변경해 내장 사이드카 컨테이너가 지원되고 실행 중임을 나타낸다. OldWaySidecar라고 부르는 일반 컨테이너를 주입한다. OldWaySidecar는 시작 시 빈 디렉터리에 파일이 존재하는지 확인한다. 파일이 NativeSidecar가 실행되고 있지 않음을 나타내면, 사이드카 기능이 지원되지 않는다고 가정하고 자신이 사이드카라고 가정하고 동작한다. 파일이 NativeSidecar가 실행 중임을 나타내면, (파드의 restartPolicy=Always인 경우) 아무것도 하지 않고 영원히 sleep하거나, (파드의 restartPolicy!=Always인 경우) exit code 0으로 즉시 종료한다.

다음 단계

더 알아보기 (Learn more)