[쿠버네티스 교과서] k8s 스터디 6주차 - 11장, 12장
24.09.27 ~24.09.30
k8s 사내 스터디에서 쿠버네티스 교과서 9, 10 장을 읽으며 공부한 내용
11. 애플리케이션 개발: 개발 워크플로와 CI/CD
Dockerfile - 스크립트 어플리케이션 빌드 및 패키징
docker-compose, 쿠버네티스 - 어플리케이션 실행
쿠버네티스의 이미지 구분 방법
- 태그 명시적 지정 X -> 레지스트리에서 이미지 내려받기
- 태그 지정 -> 로컬 이미지나 노드 내 이미지 캐시 사용 가능
개발 워크 플로
- 개발자 깃 푸시
- 깃 변경 확인 시 빌드 파이프라인 실행
- 이미지 빌드
- 클러스터에 어플리케이션 배치
곡스 (Gogs) -> 빌드팩 (BuildPack) 을 사용한 빌드킷 (BuildKit)
- 곡스 (Gogs) : 깃 서버
- 빌드킷 (BuildKit) : 도커 엔진 대신 이미지 빌드 가능
- 빌드팩 (BuildPack) : Dockerfile 없이 이미지 빌드 가능하게 하는 팩
CI/CD 전용 네임스페이스
네임스페이스는 다른 네임스페이스와 격리되어, 동일한 어플리케이션 동일 객체 이름으로 배치 가능
컨트롤러는 자신의 네임스페이스 안에서만 관리 대상 파드 찾음
네임스페이스 옮기며 작업해야함
cli 는 휴먼에러 가능성 있어 컨텍스트 (context) 라는 기능 존재
default 네임스페이스인 현재 컨텍스트를 다른 namespace 로 전환 가능
클러스터 전환도 가능
이미지를 레지스트리에 푸시할 수 있어야 쿠버네티스가 다운받아 컨테이너 실행 가능
레지스트리 인증정보를 비밀값 객체로 만들어 사용 가능
12. 자기수복형 애플리케이션 활용하기
자기 수복형 어플리케이션 (self-healing applicaiton)
- 클러스터 자체에서 일시적인 문제를 찾아 해결할 수 있는 어플리케이션
- 일시적인 문제를 사람 개입 없이 해결 가능
컨테이너 프로브 (container probe)
- 쿠버네티스에서 어플리케이션의 정상 상태 여부를 판단하는 기능
- 파드 정의에 기술되며, 상태 판단 지표를 반환
레디니스 프로브 (readiness probe)
- 네트워크 수준의 조치
- 비정상으로 판단되면 해당 파드는 준비대상, 서비스 활성 파드 목록에서 제외
- 즉, 트래픽을 못받음
- 서비스 비정상 확인되어 서비스 제외된 후, 다시 체크시 정상이면 서비스 복귀
- 헬스체크 기능이 없다면, 쿠버네티스는 파드가 고장난지 판단 불가 -> 고장난 컨테이너도 엔드포인트 존재
리브니스 프로브 (liveness probe)
- 컴퓨팅 수준의 조치 (파드 컨테이너 재시작)
- 파드 자체는 원래 있던 노드에 그대로 남음
프로브는 어플리케이션 업데이트 중에도 유용
- 롤아웃은 새로 투입된 파드가 준비상태 되어야 다음 롤아웃 진행
- 프로브 상태 체크가 실패하면 롤아웃 진행되지 않음
- 프로브가 서버 준비될 때까지 트래픽 전달 안되게 함
크래시루프백오프 (CrashLoopBackOff)
- 파드 재시작이 계속되지만 정상실행이 되지 않으면 크래시루프백오프 상태가 됨
- 해당 상태가 되었다면 스스로 수복할 수 없는 상태
- 해당 상태의 경우는 롤백이 필요
헬름은 원자적 설치와 업그레이드 지원
해당 작업이 실패하면 자동 롤백 기능 존재
롤아웃 상태 파악해 지정된 기간 안에 성공 못하면 자동 롤백
파드는 노드의 CPU 메모리를 사용하는데 제한이 없는데, 두 가지 문제 존재
- 메모리가 고갈되어 어플리케이션 강제 종료 위험
- 다른 어플리케이션 실행할 노드의 리소스 부족해질 위험
파드 정의에서 컨테이너 사용 리소스 총량 제한 가능
성능 테스트를 통해 리소스 사용량 측정
리소스가 부족하면 파드가 생성되지 않음
문제
1. userlink / calendar v2 의 개발 ~ 배포의 워크플로우를 CI/CD와 관련하여 설명하시오.
2. 롤아웃 시 새로운 파드가 완전히 준비된 후, 트래픽을 옮기고 싶다면 어떤 기능을 사용해야 하는가?