원샷 컨테이너

오류 발생 시 복구를 처리하는 방법에 따라 2가지 유형의 원샷 컨테이너가 있습니다. 이 두 가지 접근 방식은 "--restart"라는 CLI 수정자에서 구분됩니다.

이 수정자의 값을 "OnFailure"로 지정하면 kubectl run에 의해 생성된 리소스가 깨끗한 방식으로 종료되지 않는 경우 다시 시작됩니다(종료 반환 코드를 사용하여 확인).

이 수정자의 값이 "Never"이면 리소스/포드가 종료되는 방식에 관계없이 아무 작업도 수행하지 않습니다.

일정 컨테이너

kubectl run 명령에 "--schedule"이라는 수정자를 사용하면 cron 표현식을 제공하고 그에 따라 포드를 예약할 수 있습니다. 원샷 컨테이너 수정자는 일정 수정자와 함께 사용할 수도 있습니다.
다음은 컨테이너를 예약하기 위한 명령입니다.

# Sample command
kubectl create cronjob <job-name> --schedule="<schedule>" --restart=OnFailure --image=<image-name> -- <command-to-container>
# E.g. Command
kubectl create cronjob test-cronjob --schedule="*/3 * * * *" --restart=OnFailure --image=alpine -- sleep 10

실패 시 재시작 및 일정이 있는 컨테이너의 예는 특정 빈도로 데이터 배치에 대해 작업해야 하는 배치 작업입니다.

명령 도움말 매개변수

저는 직관적인 다단계 스위치를 사용하여 해당 주제에 대한 도움말을 제공하는 명령을 좋아합니다. 고맙게도 kubectl은 키워드를 자동 완성할 뿐만 아니라 모든 수준에서 사용 가능한 모든 CLI 옵션, 의미 및 몇 가지 좋은 예에 대한 "-h"스위치 표시 도움말을 제공할 수 있습니다. 나는 개발자들이 CLI를 정말 훌륭하고 유용하게 만들기 위해 생각하는 것을 좋아합니다. 특히 나 같은 사람(최소한의 메인 메모리를 가진)이 그것을 사용하고 있을 때 그렇습니다! ;)

로그의 단점

kubectl이 지원하는 로그 명령어는 단지 제한 없음인 것 같습니다. 데이터를 가져올 수 있는 포드의 수는 단 8개입니다! 내부적으로 API 서비스로 왕복하고 8(매직 넘버 ;) 이상)은 전체 Kubernetes 아키텍처의 중심 부분인 API 레이어에 해로운 것으로 보이기 때문에 의미가 있습니다.

이전에 언급했듯이 필터 없이 실행될 때 logs 명령은 단일 포드(라운드 로빈도 아님)에 래치되는 것처럼 보이므로 kubectl의 logs 명령이 작업이 진행되는 동안 로컬 개발에 좋은 것처럼 느껴지지만 프로덕션 환경에서 실행하기에 좋은 선택은 아닙니다.

Kubenetes의 내 애플리케이션은 클라우드용이며 특히 AWS에서 제공하는 EKS(AWS Managed Kubernetes Cluster)이므로 EKS를 사용하는 동안 이 "로깅"부분을 정말 잘 찾아야 할 것 같습니다. (아직 EKS를 직접 보지는 않았지만 내 몸의 모든 섬유는 AWS가 모든 로그를 기본적으로 CloudWatch 로그로 라우팅하는 옵션을 지원했을 것이라고 말하고 있습니다)

Kubernetes 교육/과정Stern에서 학습한 로그를 관리하는 옵션 중 하나입니다.

고물

좋은 도구인 것 같습니다. 사용해 보았지만 일반 로그에 있는 모든 옵션에 더하여 더 많은 옵션이 있습니다. 나는 모든 사람들이 이것을 현지에서 사용하도록 권장합니다.

항목 삭제

# Multiple resources can be deleted together
kubectl delete "<resource-type>/<resource-name>" "<resource-type>/<resource-name>"

삭제는 바로 삭제를 의미하지 않습니다! 포드가 "종료 중"상태로 이동한 다음 마침내 종료되는 동안 여전히 대기 시간을 따릅니다.

훗, 예상했던 글이 길어졌어...