K8S 포드에서 컨테이너를 지속적으로 실행하는 방법은 무엇입니까? 이 방법을 놓치지 마세요

어떤 목적으로 인해 Kubernetes의 Pod에서 여러 컨테이너를 지속적으로 실행해야 하는 경우가 있습니다. 이러한 종류의 게임에서는 의도한 실행, 즉 Kubernetes 작업이 명확하게 종료됩니다. 그러나 Job이 Pod에서 여러 컨테이너를 실행할 수 있더라도 실행 방법은 동시입니다.

한 가지 방법은 비즈니스 계층에서 처리하는 것입니다. 예를 들어 공유 로컬 볼륨과 파일 잠금 메커니즘을 사용하면 여러 개의 동시 컨테이너를 순차적으로 실행할 수 있습니다. 그러나 이를 위해서는 비즈니스 로직에서 강제로 동시성을 동기화로 변경해야 하므로 개발 복잡성이 증가합니다. Kubernetes 자체 메커니즘을 사용하여 구현할 수 있다면 개발 작업량이 많이 줄어들 것입니다.

여기에 세 가지 옵션이 더 있습니다.

조사 결과 컨테이너는 순차적으로 실행할 수 없지만 initContainers는 실행할 수 있는 것으로 나타났습니다. 컨테이너가 실행되기 전에 수행되는 초기화 작업으로, 실행이 완료될 때까지 공식 컨테이너가 실행되지 않으며 예외가 없습니다. 이를 활용하면 이전 작업을 initContainers에 쓰고 마지막 작업을 컨테이너에 기록하여 여러 작업을 순차적으로 실행할 수 있습니다.

다음은 3개의 Container가 순차적으로 실행되는 예입니다.

작업이 완료된 후 로그는 다음과 같습니다.

이전에 kube-batch로 알려진 Volcano는 일정 및 관리 측면에서 기본 작업을 최적화했다고 주장합니다. 그러나 핵심 로직은 여전히 ​​동일하며 지정된 컨테이너의 순차적 실행을 지원할 수 없습니다.

상태 전이 다이어그램은 다음과 같습니다.

stateDiagram [ ] → Pending Pending → Aborted Pending → Running Aborted → Pending Running → Aborted Running → Completed Running → Terminating Completed → [ ** * ] 종료됨 → []

실제 테스트에서는 현재 비즈니스 시나리오에서 기본 Job에 비해 어떤 이점도 발견되지 않았습니다. 다음은 실제 테스트된 구성입니다.

네이티브 버전과 비교하면 추가 작업이 있긴 하지만 이는 개념의 레이어일 뿐 기능적인 측면에서는 도움이 되지 않습니다.

작업이 완료된 후 로그는 다음과 같습니다.

또한 Volcano 문서가 심각하게 누락되어 kube-batch와 호환되지 않습니다. 현재로서는 불분명한 문제가 많은 것 같습니다.

argo는 순서와 종속성에 따라 실행하는 데 더 적합합니다. 그러나 평가 결과 중대한 결함이 있어 현재 시나리오에 적합하지 않은 것으로 나타났습니다.

argo의 각 작업은 독립적인 포드이며, 서로 다른 포드가 동일한 시스템에 있을 수 없습니다. 볼륨은 NFS와 같은 네트워크 스토리지 위치를 사용해야 하며 해당 성능은 집중적인 로컬 IO가 필요한 특정 시나리오를 충족하지 않습니다.

argo는 가장 적절한 형식이며 initContainers를 사용하는 사악한 방식을 피할 수 있습니다. 그러나 독립 포드는 문제로 인해 이 시나리오에 적합하지 않습니다.

현재로는 네이티브 잡이 가장 적합한 것 같습니다.

화산을 선택하려면 좀 더 심층적인 이해가 필요합니다.