728x90
해당 포스팅은 "쿠버네티스 인 액션"을 공부하고 정리한 글입니다. 모든 내용은 해당 도서를 기준으로 합니다.
⬛ 4장 레플리케이션과 그 밖의 컨트롤러 : 관리되는 파드 배포
파드
- 배포 가능한 기본 단위
- 레플리케이션컨트롤러 또는 디플로이먼트와 같은 유형의 리소스를 생성해 실제 파드를 생성하고 관리함
- 관리되지 않은 파드를 생성하면 파드를 실행할 클러스터 노드가 선택되고 파드의 컨테이너가 해당 노드에서 실행 됨
- 노드 전체에 장애가 발생하면 노드에 있는 파드는 유실되며 레플리케이션컨트롤러나 그와 유사한 기능을 하는 컨트롤러가 해당 파드를 관리하지 않는 한 새로운 파드로 대체되지 않음
◼️ 4.1 파드를 안정적으로 유지하기
쿠버네티스 주요 이점
- 쿠버네티스에 컨테이너 목록을 제공하면 해당 컨테이너를 클러스터 어딘가에서 계속 실행되도록 할 수 있는 것
- 파드가 노드에 스케줄링 되는 즉시 해당 노드의 kubelet은 파드의 컨테이너를 실행하고 파드가 존재하는 한 컨테이너가 계속 실행되도록 할 것.
- 컨테이너의 주 프로세스에 크래시가 발생하면 kubelet이 컨테이너를 다시 시작함.
- 쿠버네티스에서 애플리케이션을 실행하는 것만으로도 자동으로 치유할 수 있는 능력이 주어짐.
▪️ 4.1.1 라이브니스 프로브 소개
라이브니스 프로브(liveness probe)
- 쿠버네티스는 라이브니스 프로브를 통해 컨테이너가 살아 있는지 확인함.
- 파드의 스펙에 각 컨테이너의 라이브니스 프로브를 지정할 수 있음.
- 주기적으로 프로브를 실행하고 프로브가 실패할 경우 컨테이너를 다시 시작함.
컨테이너에 프로브를 실행하는 메커니즘
- HTTP GET 프로브 : 지정한 IP 주소, 포트, 경로에 HTTP GET 요청을 수행.
- 프로브가 응당을 수신하고 응답 코드가 오류를 나타내지 않는 경우 프로브가 성공했다고 간주됨.
- 서버가 오류 응답 코드를 반환하거나 응답하지 않으면 프로브가 실패한 것으로 간주돼 컨테이너를 다시 시작함.
- TCP 소켓 프로브 : 컨테이너의 지정된 포트에 TCP 연결을 시도함.
- 연결에 성공하면 프로브가 성공한 것.
- 연결에 실패하면 컨테이너가 다시 시작됨.
- Exec 프로브 : 컨테이너 내의 임의의 명령을 실행하고 명령의 종료 상태 코드를 확인함.
- 상태 코드가 0이면 프로브가 성공한 것.
- 상태 코드가 0이 아니면 실패로 간주됨.
▪️ 4.1.2 HTTP 기반 라이브니스 프로브 생성
쿠버네티스가 주기적으로 ‘/’ 경로와 8080 포트에 HTTP GET을 요청해서 컨테이너가 정상 동작하는지 확인하도록 httpGet 라이브니스 프로브를 정의함.
▪️ 4.1.5 효과적인 라이브니스 프로브 생성
프로세스가 실행되는 한 쿠버네티스는 컨테이너가 정상적이라고 간주할 것.
라이브니스 프로브가 확인해야 할 사항
- 특정 URL 경로에 요청하도록 프로브를 구성해 애플리케이션 내에서 실행 중인 모든 주요 구성 요소가 살아 있는지 또는 응답이 없는지 확인하도록 구성할 수 있음.
- 라이브니스 프로브는 애플리케이션의 내부만 체크하고 외부 요인은 영향을 받지 않도록 해야 함.
- 너무 많은 연산 리소스를 사용해서는 안됨. 완료하는데 너무 오래 걸리지 않아야 함.
- 쿠버네티스는 실패를 한 번했다고 간주하기 전에 프로브를 여러 번 재 시도하기 때문에 프로브에 자체적인 재시도 루프를 구현하지 않아야 함.
라이브니스 프로프가 실패한 경우
- 쿠버네티스가 컨테이너를 재시작해 컨테이너가 계속 실행되도록 함.
- 이 작업은 파드를 호스팅하는 노드의 kubelet에서 수행함.
- 마스터에서 실행 중인 쿠버네티스 컨트롤 플레인 구성 요소는 이 프로세스에 관여하지 않음.
- 노드 자체에 크래시가 발생한 경우 노드 크래시로 중단된 모든 파드의 대체 파드를 생성해야 하는 것은 컨트롤 플레인 몫임.
- kubelet은 노드에서 실행되기 때문에 노드 자체가 고장 나면 아무것도 할 수 없음.
◼️ 4.2 레플리케이션컨트롤러 소개
레플리케이션컨트롤러
- 쿠버네티스 리소스로서 파드가 항상 실행되도록 보장함.
- 클러스터에서 노드가 사라지거나 노드에서 파드가 제거된 경우 레플리케이션컨트롤러는 사라진 파드를 감지해 교체 파드를 생성함.
- 파드 A는 직접 생성해 관리되지 않는 파드인 반면 파드 B는 레플리케이션컨트롤러에 의해 관리됨.
- 노드 장애가 발생한 후 레플리케이션컨트롤러는 사라진 파드 B를 고체하기 위해 새 파드를 생성하지만 파드 A는 완전히 유실됨.
- 레플리케이션컨트롤러는 파드의 여러 복제본을 작성하고 관리하기 위한 것.
▪️ 4.3.1 레플리케이션컨트롤러의 동작
레플리케이션컨트롤러 역할
- 실행 중인 목록을 지속적으로 모니터링.
- 특정 유형의 실제 파드 수가 의도하는 수와 일치하는 지 항상 확인.
- 파드가 너무 적게 실행 중이면 파드 템플릿에서 새 복제본 생성.
- 파드가 너무 많으면 초과 복제본 제거.
- 정확한 수의 파드가 항상 레이블 셀렉터와 일치하는지 확인.
레플리케이션컨트롤러의 세 가지 요소 이해
- 레이블 셀렉터 : 레플리케이션컨트롤러의 범위에 있는 파드 결정.
- 레플리카 수 : 실행할 파드의 의도하는 수를 지정.
- 파드 템플릿 : 새로운 파드 레플리카를 만들 때 사용.
레이블 셀렉터를 변경하면
- 기존 파드가 레플리케이션컨트롤러의 범위를 벗어나므로 컨트롤러가 해당 파드에 대한 관리를 중지함.
- 파드를 생성한 후에는 파드의 실제 콘텐츠에 신경을 쓰지 않음.
- 탬플릿은 레플리케이션컨트롤러로 새 파드를 새엉할 때만 영향을 미침.
레플리케이션컨트롤러 사용 이점
- 기존 파드가 사라지면 새 파드를 시작해 파드가 항상 실행되도록 함.
- 클러스터 노드에 장애가 발생하면 장애가 발생한 노드에서 실행 중인 모든 파드에 관한 교체 복제본 생성.
- 수동 또는 자동으로 파드를 쉽게 수평 확장 가능.
컨트롤러가 새로운 파드를 생성한 원인
- 컨트롤러가 새 교체 파드를 만들어 파드 삭제에 대응함.
- 삭제 그 자체에 대한 대응이 아니라 결과적인 상태(부족한 파드 수)에 대응하는 것.
- 대체 파드를 생성하게 하는 것이 아니라 컨트롤러가 실제 파드 수를 확인하고 적절한 조치를 취하도록 하는 트리거 역할을 함.
노드 장애 대응
- 레플리케이션컨트롤러는 노드의 파드가 다운됐음을 감지하자마자 파드를 대체하기 위해 새 파드를 기동함.
▪️ 4.2.4 레플리케이션컨트롤러의 범위 안팎으로 파드 이동하기
레플리케이션컨트롤러가 생성한 파드는
- 어떤 식으로든 이 레플리케이션컨트롤러와 묶이지 않음.
- 레이블 셀럭터와 일치하는 파드만 관리.
- 파드의 레이블을 변경하면 레플리케이션컨트롤러의 범위에서 제거되거나 추가될 수 있음.
- 레플리케이션컨트롤러에서 다른 레플리케이션컨트롤러로 이동할 수도 있음.
- 파드 레이블이 더 이상 레플리케이션컨트롤러의 파드 셀렉터와 일치하지않도록 변경했을 때 발생한 상황.
- 파드의 레이블을 app=kubia에서 app=foo로 변경하면 레플리케이션컨트롤러가 더 이상 해당 파드를 신경쓰지 않음.
- 컨트롤러의 레플리카 수가 3으로 설정 되어 있기 때문에 레플리케이션컨트롤러는 파드 kubia-2qneh를 기동시켜 파드 수를 다시 세개로 만듦.
컨트롤러에서 파드를 제거하는 사례
- 파드가 오작동하는 것을 알게 되면 파드를 레플리케이션컨트롤러의 범위 밖으로 빼내 컨트롤러가 새 파드로 교체하도록 함.
- 이후 원하는 방식으로 파드를 디버그하거나 문제를 재연해 볼 수 있음.
- 완료되면 파드를 삭제함.
- 파드 탬플릿은 언제든 수정 가능.
- 나중에 잘라낼 쿠키에만 영향을 줄 뿐 이미 잘라낸 쿠키에는 아무런 영향을 미치지 않음.
▪️ 4.2.6 수평 파드 스케일링
파드 수평으로 스케일링(확장)
- 레플리케이션컨트롤러 리소스의 replicas 필드 값을 변경하면 됨.
kubectl scal rc <name> --replicas=10
kubectl scale 명령
- 쿠버네티스에게 무언가를 하라고 알려주는 게 아니라 레플리케이션컨트롤러의 의도하는 상태를 선언적으로 변경하는 것.
레플리케이션컨트롤러 삭제
- 레플리케이션컨트롤러만 삭제하고 파드는 실행 상태로 둘 수 있음.
- 파드에 영향을 주지 않고 수행할 수 있으며 파드를 관리하는 레플리케이션컨트롤러를 교체하는 동안 중단 없이 실행할 수 있음.
- 레플리케이션컨트롤러를 삭제 해 파드가 어디에도 속해있지 않으면 더 이상 관리되지 않음.
- 언제든 적절한 레이블 셀렉터를 사용하는 새 레플리케이션컨트롤러를 작성해 다시 관리할 수 있음.
◼️ 4.3 레플리케이션컨트롤러 대신 레플리카셋 사용하기
레플리카셋(replicaset)
- 차세대 레플리케이션컨트롤러.
- 레플리케이션컨트롤러를 완전히 대체할 것.
- 레플리케이션컨트롤러와 거의 동일함.
- 레플리카셋의 셀렉터는 특정 레이블이 없는 파드나 레이블의 값과 상관없이 특정 레이블의 키를 갖는 파드를 매칭시킬 수 있음.
- 하나의 레플리카셋으로 두 파드 세트를 모두 매칭시켜 하나의 그룹으로 취급할 수 있음.
- 실제 값이 무엇이든 env 키가 있는 레이블을 갖는 모든 파드를 매칭시킬 수 있음.
레이블 셀렉터
- 레플리카셋의 주요 개선 사항으로 좀 더 표현적인 레이블 셀렉터.
- In은 레이블 값이 지정된 값 중 하나와 일치해야 함.
- NotIn은 레이블의 값이 지정된 값과 일치하지 않아야 함.
- Exists는 파드는 지정된 키를 가진 레이블이 포함돼야 함.
- DoesNotExist는 파드에 지정된 키를 가진 레이블이 포함돼 있지 않아야 함.
- matchLabels와 matchExpressions을 모두 지정하면 셀렉터가 파드를 매칭하기 위해서는 모든 레이블이 일치하고 모든 표현식이 true로 평가돼야 함.
◼️ 4.4 데몬셋을 사용해 각 노드에서 정확히 한 개의 파드 실행하기
- 클러스터의 모든 노드에 노드 당 하나의 파드만 실행되길 원하는 경우.
- 데몬셋(DaemonSet) 오브젝트를 생성해야 함.
- 데몬셋에 의해 생성되는 파드는 타깃 노드가 이미 지정돼 있고 쿠버네티스 스케줄러를 건너뛰는 것을 제외하면 이 오브젝트는 레플리케이션컨트롤러 또는 레플리카셋과 매우 유사함.
- 파드가 클러스터 내에 무작위로 흩어져 배포되지 않음.
- 노드 수 만큼 파드를 만들고 각 노드에 배포함.
- 데몬셋에는 원하는 복제본 수라는 개념이 없음.
- 파드 셀레겉와 일치하는 파드 하나가 각 노드에서 실행 중인지 확인하는 것이 데몬셋이 수행해야 하는 역할이기 때문.
- 노드가 다운되면 데몬셋은 다른 곳에서 파드를 생성하지 않음.
- 새 노드가 클러스터에 추가되면 데몬셋은 즉시 새 파드 인스턴스를 새 노드에 배포함.
◼️ 4.5 완료 가능한 단일 테스크를 수행하는 파드 실행
▪️ 4.5.1 잡 리소스
잡 리소스
- 쿠버네티스는 잡 리소스로 완료 가능한 태스크에서 프로세스가 종료된 후에 다시 시작되지 않도록 함.
- 잡은 파드의 컨테이너 내부에서 실행 중인 프로셋가 성공적으로 완료되면 컨테이너를 다시 시작하지 않는 파드를 실행할 수 있음.
- 노드에 장애가 발생한 경우 해당 노드에 있던 잡이 관리하는 파드는 레플리카셋 파드와 같은 방식으로 다른 노드로 다시 스케줄링 됨.
- 프로세스 자체에 장애가 발생한 경우 잡에서 컨테이너를 다시 시작할 것인지 설정할 수 있음.
- 관리되지 않은 파드에서 작업을 실행하고 완료될 때까지 기다릴 순 있지만 작업이 수행되는 동안 노드에 장애가 발생하거나 파드가 노드에서 제거되는 경우 수동으로 다시 생성함.
- 두 개 이상의 파드 인스턴스를 생성해 병렬 또는 순차적으로 실행하도록 구성할 수 있음.
◼️ 4.6 잡을 주기적으로 또는 한 번 실행되도록 스케줄링 하기
잡 리소스 생성 시
- 즉시 해당하는 파드를 실행함.
- 많은 배치 잡이 미래의 특정 시간 또는 지정된 간격으로 반복 실행해야 함.
- 크론(cron) 작업.
크론 작업
- 크론잡 리소스를 만들어 구성.
- 설정된 시간에 잡 리소스를 크론잡 오브젝트에 설정한 잡 템플릿에 따라 생성함.
- 스케줄은 왼쪽에서 오른쪽으로 다섯 개 항목을 가짐.
- 분, 시, 일, 월, 요일
- 매시간, 매일, 매월, 모든 요일의 0, 15, 30, 45분에 실행됨을 의미하기 때문에 스케줄은 0, 15, 30, 45 * * * * 이 되는 것.
728x90
