포드 상태 및 수명주기 관리
첫째, 포드는 무엇인가?
둘째, 방법 포드 여러 컨테이너를 관리하는?
셋째, 사용 포드
넷째, 지속성과 포드의 종료
다섯, 일시 정지 용기
여섯, 초기화 용기
세븐, 포드 수명주기
(1)상의 포드 (포드 상)
제작 과정 (2) 포드
(3) 상태 포드
(4) 포드 생존 프로브
(5) livenessProbe 사용 시나리오와 readinessProbe
(6) 포드를 다시 시작 전략
(7) 포드 생활
(8) livenessProbe의 해결
첫째, 포드는 무엇인가?
포드 작성하고 가장 작고 간단한 장치를 배포 할 수는 Kubernetes입니다. 포드는 클러스터에서 실행중인 프로세스를 나타냅니다.
컨테이너 응용 프로그램에 캡슐화 포드 컨테이너 정책 옵션의 작동을 관리하는 방법, 저장, 독립적 인 네트워크 IP, (어떤 경우에는 몇 가지 용기입니다). 포드는 배포 단위를 나타냄는 Kubernetes 한 예에 적용, 또는 자원을 함께 공유하는 복수의 용기의 조합 일 수있다.
Kubrenetes 클러스터에서 포드는 두 가지 방법을 다음과 같은 :
포드는 컨테이너를 실행합니다. 모드 "컨테이너의 각 포드는"가장 일반적인 사용법이다이 사용에서, 당신은 포드가 하나의 용기에 포장되어 상상할 수있는, 직접 컨테이너를 관리되지 포드 관리를 kuberentes.
동시에 창에 복수의 컨테이너를 실행. 패키지에서 포드 동시에 단단히, 일부 상호 컨테이너에 결합 된 그 (것)들의 사이에서 자원을 공유 할 수 있습니다. 컨테이너 파일 공유,이 파일을 업데이트하는 또 다른 "사이드카"컨테이너 - 같은 포드의 이러한 컨테이너는 서비스 단위가되기 위해 서로 협력 할 수 있습니다. 이러한 컨테이너 관리 엔티티로 포드 스토리지 자원.
도커 용기와 일치 리눅스의 네임 스페이스, cgroup의 가능성이 다른 격리 된 환경을 포함하여 공유 환경에서 포드. 포드 환경에서, 각 용기는 작은 서브 격리 환경이있을 수있다.
컨테이너의 포드는 IP 주소를 공유 및 포트 번호는 각 로컬 호스트 사이에서 찾을 수 있습니다. 그들 간의 프로세스 간 통신에 의해, 동일 포드 LO 카드를 통해 통신중인 용기 않는 것으로 이해되어야한다. 예를 들어 시스템 V 신호 또는 POSIX 공유 메모리. 다른 컨테이너 사이 포드는 직접 IPC를 통해 통신 할 수 있고, 서로 다른 IP 주소를 가지고있다.
컨테이너의 포드는 또한 응용 프로그램 및 파일 시스템 컨테이너에 장착 된 포드의 일부로 정의 볼륨 볼륨을 공유 할 수있는 액세스 권한을가집니다.
모든 응용 프로그램 컨테이너와 마찬가지로, 포드는 임시 개체로 간주됩니다. 포드의 수명주기에서 생성 된 후 포드, 그것은 노드에서 예정 고유 ID (UID)를 할당하고,이 끝날 때까지 원하는 상태를 유지하기로 합의 (재부팅 전략에 따라) 또는 삭제됩니다. 노드가 죽은 경우 타임 아웃이 다른 노드의 노드로 재조정됩니다 후,이 노드의 포드에 할당. 원하는 경우, 소정의 포드 (정의 UID)를 신규 노드로 "재조정"되지 않지만 비슷한 모음으로 대체 된, 그것도 동일한 이름 일 수 있지만 새로운 UID있을 것이다 (자세한 내용은 복제 컨트롤러 참조).
둘째, 방법 포드 여러 컨테이너를 관리하는?
포드는 함께 일하기 (컨테이너로 실행) 여러 프로세스를 실행할 수 있습니다. 같은 컨테이너에 포드는 자동으로 동일한 노드에 할당됩니다. 공유 자원과 용기 포드, 그리고 그들이 항상 동시에 예약 된 네트워크 환경에 의존하고 있습니다.
포드의 여러 용기에 동시에 실행 참고 더 진보 된 사용합니다. 오직 당신 만이이 모델을 사용하여 고려하기 전에 시간의 협력과 용기를 닫을 필요가있을 때. 예를 들어, 실행 공유 볼륨을 사용할 필요가있는 웹 서버로 용기를 가지고, 이러한 파일을 원격으로 컨테이너 자원 업데이트를 얻을 수있는 또 다른 "사이드카가"있다,
포드는이 자원을 공유 : 네트워크 및 스토리지.
네트워크 :
각 포드는 고유 한 IP 주소를 할당됩니다. IP 주소와 포트를 포함하여 공유 네트워크 드라이브에 포드는 모든 컨테이너. 용기 내부의 포드는 로컬 호스트를 사용하여 서로 통신 할 수있다. 컨테이너가 네트워크 자원 할당을 공유 할 수있는 포드 외부와 통신 (예를 들어, 호스트 포트 맵핑을 사용).
저장 :
포드는 다수의 공유 볼륨을 지정할 수 있습니다. 포드의 모든 용기는 공유 볼륨에 액세스 할 수 있습니다. 볼륨은 다시 시작 파일이없는 후 컨테이너를 방지하기 위해 포드의 지속적인 스토리지 자원에 사용할 수 있습니다.
셋째, 사용 포드
포드는 일반적으로 두 가지 범주로 나누어 :
자율 포드 : 포드가 (직접 사용자 나 다른 컨트롤러에 의해 만들어진)는 노드 클러스터에 예정 Kuberentes 될 것입니다 만들 때 포드이 자체는 자체 복구되지 않습니다. 프로세스가 종료 포드까지, 때문에 자원의 부족, 삭제는 추방, 또는 포드 전에 노드의 실패는 노드에 유지됩니다. 포드는 치유되지 않습니다. 포드는 노드 장애 또는 장애 스케줄러 자체를 실행하는 경우, 포드가 삭제됩니다. 마찬가지로, 만약 유지 보수 상태에서 포드 포드가 포드가 추방 될 자원 또는 노드의 부족.
관리 컨트롤러 포드는 :는 Kubernetes은 고급 추상화 계층은 포드 인스턴스를 관리하는 컨트롤러를했다. 컨트롤러를 만들고 여러 포드, 관리, 관리, 롤링 업그레이드 및 클러스터 수준의 치유 능력의 사본을 제공 할 수 있습니다. 예를 들어, 노드 실패하면 컨트롤러가 자동으로 노드에서 다른 건강한 노드 포드에 예정됩니다. 직접 포드를 사용하지만입니다 수 있지만 일반적으로는 Kubernetes에서 포드를 관리하는 컨트롤러를 사용합니다. 도는 다음과 같습니다 :
각 포드는 "루트 컨테이너"라는 특수가있는 컨테이너를 일시 중지합니다. 일시 용기 제외 용기는 Kubernetes 플랫폼의 일부에 대응하는 화상을 일시 중지 또한 사용자 트래픽 또는 밀접하게 관련된 복수의 용기를 포함하고, 각 포드.
특별 구성과 목적은 무엇 구조는 Kubernetes 포드 개념 설계?
이유 : 컨테이너 단위로 그룹의 경우, 용이하고 효율적으로 결정된 동작 전체 컨테이너 어렵다. 예를 들어, 컨테이너는 죽고, 이것은 걸어 전체로 간주되었다? 문제가 해결 될 수 있도록 그 상태로 루트 컨테이너 포드 일시 정지, 용기 전체 그룹의 상태를 나타내고, 그런 다음 서비스 독립적 용기에 도입했다.
두 가지 이유 : 포드 여러 서비스 컨테이너 선박에서 공유 일시 중지 IP 공유 일시 정지 컨테이너는 컨테이너 부문 사이의 통신 문제를 단순화뿐만 아니라 용기 사이의 파일 공유의 문제를 해결 볼륨을 장착.
넷째, 지속성과 포드의 종료
의 영구 (1) 포드
포드 디자인 지원은 지속적 엔티티 없습니다. 예약 실패, 노드 장애에서, 자원의 부족은 다음 노드 상태 유지 또는 죽은 추방 될 것입니다.
일반적으로 사용자가 직접 수동으로 포드를 만들 필요가 없습니다,하지만 단 한 번의 포드를 만드는 경우, 컨트롤러 (예를 들어, 배포)를 사용합니다. Controller 클러스터 수준은자가 치유 기능, 복제를 제공 및 관리를 업그레이드 할 수 있습니다.
(2) 포드 종료
때문에 포드 프로세스가 클러스터의 노드에서 실행되는, 그래서 때 더 이상 정상적으로 오프 종료해야 할 필요 (예 : 폭력을 사용하여 KILL 신호를 전송하는 것보다 방법)입니다. 사용자는 삭제 요청을 완화 할 수 있어야하고, 그들은이 종료 될 때, 제대로 제거 된 것을 알고있다. 포드 사용자가 프로그램을 종료 요청을 보내려고 삭제, 포드 강제 TERM 각 용기의 주 프로세스에 요청을 보냅니다 제거 할 수 있습니다 전에 유예 기간이있을 것이다. 타임 아웃되면, 주요 프로세스는 KILL 신호를 보낼 것이고, API 서버에서 제거합니다. 다시 시작을 종료하는 과정을 기다리는 동안 kubelet 또는 컨테이너 관리하는 경우, 다시 시작한 후 여전히 완전한 은혜를 시도됩니다.
예를 들어 다음과 같이 과정은 :
사용자는 포드를 삭제하는 명령을 전송, 기본 유예 기간은 30 초입니다;
포드 API 서버와 유예 기간 포드 후 "죽음"의 상태를 업데이트합니다;
클라이언트 명령 행에서 포드 상태 표시 "종료"입니다;
kubelet가 포드 "종료"상태로 표시되는 발견 번째 단계와 동시에 처리를 시작 창을 정지 상태 :
당신은 포드에서 preStop 후크를 정의하는 경우, 그것은 포드를 중지하기 전에 호출됩니다. 유예 기간이있는 경우, 여전히 실행에 preStop 훅은 제 2 단계의 유예 2 초에 추가하는 것;
송신 과정에서 TERM 신호 포드;
한편, 포드는 세 번째 단계로 서비스에서 삭제 된 엔드 포인트 목록은 복제 컨트롤러의 더 이상 일부입니다. 느린 포드 꺼짐 트래픽 부하 분산 장치의 전달을 처리 할 것입니다;
유예 기간 후, 프로세스는 여전히 프로세스를 종료하기 위해 SIGKILL 신호를 보내 포드에서 실행됩니다.
우아한 기간을 0으로 설정하여 Kublete 포드가의 API 서버의 제거를 완료합니다 (즉시 삭제). 포드는 API 사라, 클라이언트에 표시되지 않습니다.
기본 유예 기간을 삭제하는 것은 30 초입니다. 명령 -grace 기간 =를 지원 삭제 kubectl <초> 옵션은 사용자가 자신의 은혜를 설정할 수 있습니다. 0으로 설정하면 제거 포드를 강제 할 것이다. 명령> = 1.5 버전 kubectl, 당신은 포드를 삭제 강제로 --force 및 --grace 기간 = 0을 사용해야합니다.
포드는 강제로 클러스터의 상태에서 그 정의에 의해 삭제 및 삭제 etcd된다. 삭제 명령을 강제하는 경우, API 서버가 확인 kubelet 노드에서 실행중인 포드 기다리지 않습니다, 그것은 바로 포드 API를 서버에서 제거됩니다, 당신은 원래 포드와 같은 이름을 가진 포드를 만들 수 있습니다. 이 때, 노드에서 포드는 즉시 상태를 종료하지만 여전히 삭제 짧은 기간 우아함을 강제로 삭제되기 전에 설정됩니다.
다섯, 일시 정지 용기
인프라 컨테이너로 알려진 일시 정지 용기. 각 노드에서 시간을 발견 할 것이다 우리는 확인 노드 노드는 일시 정지 용기를 많이 실행
컨테이너는 다음과 같은 기능을 주로 제공하는 각 컨테이너 서비스 일시 정지는 Kubernetes :
포드의 기본 네임 스페이스를 공유 리눅스;
, PID 네임 스페이스를 사용 init 프로세스를 엽니 다.
결심
호스트 네트워크 네임 스페이스에 설정 한 일시 정지 컨테이너 후 8880 포트를 호스팅하는 컨테이너 포트 (80)의 내부를 매핑 일시 정지, nginx를 용기가 네트워크 네임 스페이스에 추가, 우리는 nginx를 컨테이너가 지정된 시작 시간을 참조 --net = 용기 : 공유 네트워크에있는 세 개의 용기가 서로 로컬 호스트로 사용하여 직접 통신 할 수 있도록 일시, 유령 같은 용기는, 네트워크의 공간에 첨가 - = IPC contianer을 : --pid = 용기를 일시 정지 : 정지 세이며 , 초기화 과정에서 같은 네임 스페이스의 용기는 우리가 처리 상황을 확인하기 위해 유령 용기에 입력, 일시 정지입니다.
동시에 당신은 유령 컨테이너 프로세스 일시 정지 및 Nginx에 컨테이너를 볼 수 있고, 컨테이너는 1 PID 일시 정지입니다. PID 프로세스 컨테이너는 Kubernetes에서 = 1은 비즈니스 프로세스 컨테이너 자체입니다.
여섯, 초기화 용기
포드는 용기 내에서 실행되는 용기, 복수의 애플리케이션을 가질 수 있지만, 또한 초기화 컨테이너 선박의 개시 이전에 하나 개 이상의 애플리케이션을 가질 수있다.
다음 두 가지 사항을 제외하고 많은 일반 컨테이너와 같은 초기화 선박 :
초기화 컨테이너는 항상 성공적으로 완료에 실행합니다.
각 컨테이너는 성공적으로 다음 시작 초기화 용기 전에 완료해야 INIT.
포드의 초기화 용기 실패하는 경우는 Kubernetes는 성공할 때까지 포드, 초기화 컨테이너를 다시 시작하는 것입니다. 해당 restartPolicy 포드는 절대로하지 않는 경우 그러나, 그것은 다시 시작하지 않습니다.
초기화 컨테이너는 컨테이너의 시작은 이름이 여러 개있을 경우 첫 번째, 하나 개 이상의 컨테이너가 될 수 시작, 그래서이 초기화 컨테이너가 순차적으로 모든 초기화 컨테이너의 구현 이후에만 정의 된 순서대로 실행, 주요 컨테이너 될 것입니다 것입니다, 제안 할 때 시작합니다. 공유 저장 볼륨에서 포드 이후 초기화 컨테이너 주 용기에서 생성 된 데이터에 사용될 수있다. 초기화 컨테이너 K8S에서 다양한 자원에 초기 작업을 수행 포드 시작 수행을 시작하기 전에 주 용기에, 등 등의 배포, 데몬 세트, 애완 동물 세트, 작업에 사용하지만, 마지막에 할 수 있습니다.
시나리오 :
첫 번째 시나리오 : 준비 다른 모듈을 기다리고, 예를 들어, 우리는 두 개의 컨테이너 서비스를 제공하는 응용 프로그램이 웹 서버, 다른 데이터베이스입니다. 어떤 웹 서버가 데이터베이스에 액세스해야합니다. 우리는 데이터베이스 서비스가 먼저 시작 보장하지 않습니다이 응용 프로그램을 시작할 때, 시간이 웹 서버는 데이터베이스 연결 오류가 나타날 수 있습니다. 데이터베이스가 연결 될 때까지이 문제를 해결하기 위해, 포드는 우리가 준비 데이터베이스를 확인할지 여부, 웹 서버 서비스의 사용 InitContainer를 실행할 수 초기화 컨테이너 출구가 끝나기 전에, 다음 웹 서버 컨테이너는 공식 데이터베이스 연결 요청을 시작하는 활성화 . 두 번째 시나리오 : 초기 구성, 이미 존재하는 등 클러스터 노드의 모든 구성원 검출로, 주로 클러스터 구성 데이터에 대한 준비가 용기, 그래서 클러스터를 구성하기 위해이 정보를 사용할 수 있습니다 후 주요 컨테이너입니다. 다른 사용 시나리오 : 포드 바와 같이 중앙 데이터베이스, 애플리케이션 다운로드 의존성에 등록합니다.
세븐, 포드 수명주기
(1)상의 포드 (포드 상)
위상 필드가 정의 PodStatus에 저장된 상태 정보의 포드.
포드 상 (상)은 라이프 사이클 포드 간단한 매크로 개요입니다. 무대는 없으며, 포괄적 인 상태 머신에 같은 용기 또는 포드의 포괄적 인 요약 아니다.
포드 단계의 수와 엄격한 의미 지정했습니다. 이 문서에 추가하여이 상태를 포함에서 더 이상 다른 위상 값 포드가 없다고 가정한다.
다음은 가능한 위상 값이다 :
일시 중지 (보류) : API 서버 자원 오브젝트가 포드를 생성하고 etcd에 저장되어 있지만,이 예약되지 않았거나웨어 하우스 프로세스에서 이미지를 다운로드에 아직도있다.
동작 (실행)은 : 포드는 노드에 예약 된 모든 용기 kubelet 만들어졌다.
성공 (성공) : 포드는 모든 컨테이너에서 성공적으로 종료되었으며, 다시 시작되지 않습니다.
실패 (실패) : 모든 컨테이너에 포드가 종료되고, 적어도 하나의 용기로 인해 실패로 종료됩니다. 즉, 컨테이너 종료 0 상태 또는 비 종료 시스템입니다.
알 수없는 (알 수 없음) : 실패가 호스트 통신 포드에게 있습니다 일반적으로하기 때문에, 상태 포드를 얻을 수없는 몇 가지 이유.
제작 과정 (2) 포드
포드는 창조의 과정을 이해뿐만 아니라 시스템의 작동을 이해하는 데 도움이, 기본 단위는 Kubernetes입니다.
① 포드 사양 사용자는 kubectl 또는 기타 API 클라이언트에 의해 API 서버에 제출했다.
②API 서버가 포드를 etcd하고 완료 쓰기 작업을 기다릴 정보 객체를 저장하려고 API 서버는 클라이언트에 승인 메시지를 리턴한다.
③API 서버 etcd의 상태의 변화를 반영하기 시작했다.
④은 "보는"기구에 의해 API 서버의 변화에 대한 정보를 관련된 모든는 Kubernetes 후속 검사 구성 요소.
그 "감시자"에 의해 감지 ⑤kube-스케줄러 (스케줄러) 서버 포드에게 객체를 새로운 API를 만들 수 있지만 작업자 노드에 바인딩되지합니다.
⑥kube - 스케줄러는 작업 포드 노드 객체를 선택하고 API 서버에 업데이트 될 수 있습니다.
이 API 서버 etcd에 스케줄링 결과에 의해 업데이트 ⑦ 소식은, 또한 객체 포드의 피드백 API 서버 스케줄링 결과를 시작.
⑧Pod의 kubelet는 대상 노드가 현재 노드에 부팅 컨테이너에 고정 표시기 엔진을 호출 시도하고 컨테이너 API 서버의 상태로 결과를 반환 작업을 할 예정이다.
⑨API 서버 정보는 포드 etcd 시스템에 저장됩니다.
etcd이 확인에 ⑩ 쓰기 작업은 API 서버는 관련 kubelet에게 확인 메시지를 전송 완료됩니다.
(3) 상태 포드
포드는 PodCondition 어레이를 포함하는 PodStatus 객체를 갖는다. PodCondition 어레이의 각 요소는 타입 필드 및 상태 필드를 갖는다. 타입 필드는 문자열, 가능한 값은, 준비 PodScheduled 초기화 Unschedulable되어있다. 상태 필드는 가능한 값은, 허위 사실 및 알 수 있으며, 문자열입니다.
(4) 포드 생존 프로브
포드의 라이프 사이클에서 우리는 그것에 대해 뭔가를 할 수 있습니다. 직렬 실행, 실행이 출시 후 완료 주요 컨테이너가 초기화 컨테이너의 시작 전에 완료 될 수있다, 컨테이너가 여러 초기화를 할 수 있습니다, 그들은되며, 주요 프로그램은 단지 주 프로그램을 시작 게시물을 지정할 수 있습니다 시작했을 때 처음 몇 가지 작업을 수행 한 후 시작 메인 프로그램의 종료 전에 사전 정지 주 프로그램이 끝나기 전에 수행 일부 작업을 나타냅니다 지정할 수 있습니다. 검출 LIVENESS 프로브 (프로브 생존)과 readness 프로브 (준비 프로브)의 두 가지 유형을 수행 할 수있는 프로그램을 시작한 후.
Kubelet 주기적 진단 프로브를 용기에 대해 수행된다. 진단, 컨테이너에 의해 구현 kubelet 호출 핸들러를 수행합니다. 방법은 세 가지를 다음의 가능성을 감지 :
ExecAction는 : 컨테이너에서 지정된 명령을 실행합니다. 0의 종료 명령의 리턴 코드가 진단 성공으로 간주됩니다.
TCPSocketAction : 확인 지정된 컨테이너 포트 TCP의 IP 주소를 입력합니다. 포트가 열려있는 경우, 진단은 성공으로 간주됩니다.
HTTPGetAction : 지정된 포트와 경로에있는 컨테이너의 IP 주소에 대한 HTTP 가져 오기 수행 요청. 200 미만 400 이상인 응답 상태 코드 후 진단이 성공한 것으로 간주하면된다.
상기 자원 매니페스트 파일은 IP 포드 가능한 상태 발신 80 / TCP 포트로 연결 요청 상태 포드 연결 설정에 따라 결정된다.
각 프로브는 세 가지 결과 중 하나 얻을 것이다 :
성공 : 진단을 통해 컨테이너입니다.
실패 : 컨테이너가 진단되지 않습니다.
알 수 없음 : 진단은 어떤 조치를 취할 것, 실패합니다.
용기에 프로브를 실행하고 반응할지 여부를 선택할 수있는 두 가지 구현을 Kubelet :
livenessProbe는 : 컨테이너가 실행되고 있는지 여부를 나타냅니다. 프로브의 생존에 실패 할 경우, kubelet 컨테이너를 죽일하며 용기는 전략의 재시작에 의해 영향을받을 것입니다. 컨테이너는 실행 가능한 프로브, 성공의 기본 상태를 제공하지 않는 경우.
readinessProbe는 : 컨테이너가 서비스 요청에 대한 준비가되었는지 여부를 나타냅니다. 프로브가 준비가 실패하면 모두가 포드의 IP 주소를 제거의 엔드 포인트 컨트롤러는 포드 서비스 끝점을 일치합니다. 초기 지연 기본 오류가 발생하기 전에 준비 상태. 컨테이너는 프로브, 성공의 기본 상태를 제공 할 준비가되지 않습니다.
(5) livenessProbe 사용 시나리오와 readinessProbe
컨테이너 프로세스가 이벤트에서 자체적으로 충돌하는 경우가 어려움이나 건강에 해로운가 발생하는 경우는 반드시 프로브를 생존 할 필요가 없습니다 kubelet 자동으로 restartPolicy 포드에 따라 옳은 일을 할 것입니다.
당신이 컨테이너가 검출 실패하고 다시 시작에서 살해하려는 경우, 생존 프로브를 지정하고, 항상 또는 OnFailure에 restartPolicy를 지정합니다.
당신이 검색이 성공에만 포드에 트래픽을 전송 시작하려면 준비 프로브를 지정합니다. 이 경우, 프로브는 같은 준비와 프로브의 생존하지만,이 포드는 트래픽을받지 않고 시작을 의미 프로브의 준비 사양 일 수 있으며, 단지 성공을 프로빙 후 시작 트래픽을받을 수 있습니다.
당신은 자신의 용기를 유지할 수 있도록하려면, 당신은 준비 프로브, 프로브 다른 검사 프로브와 생존 엔드 포인트를 지정할 수 있습니다.
당신은 포드가 배제를 요청할 수 있습니다 때 제거하려는 경우, 당신은 반드시 준비 프로브를 사용 할 필요는 없습니다, 당신은 포드를 삭제할 때, 포드는 관계없이 자동으로 준비 프로브가 있는지의 자신의 미완성 상태로 배치됩니다. 컨테이너가 대기 포드에서 정지 할 때, 포드는 불완전한 상태로 남아있다.
(6) 포드를 다시 시작 전략
PodSpec는 restartPolicy 필드 가능한 값 항상 OnFailure 결코있다. 기본값은 항상입니다. 모든 콘테이너에 적합 포드 restartPolicy. kubelet 의해 restartPolicy 동일한 노드에 다시 용기만을 말한다. 지수 적 백 오프 지연의 상한 다섯 분으로 kubelet 의한 용기의 실패 (10 초 20 초 40초 ...) 재시작 십 분 성공적인 실행 후에 재설정. 노드가 포드에 결합되면, 포드는 또 다른 노드에 바인딩되지 않습니다.
(7) 포드 생활
사람들이 그들을 파괴 할 때까지 일반적으로, 포드는 사라지지 않을 것입니다. 그것은 사람이나 컨트롤러가 될 수 있습니다. 이 규칙 (마스터 결정) 기간 포드 유일한 예외 위에 위상 성패가 만료되고 자동적으로 파괴된다.
컨트롤러는 세 가지를 사용할 수있다 :
를 사용하여 작업 실행은 벌크 계산으로, 포드를 종료 할 것으로 예상된다. 작업은 OnFailure에 대한 정책 적용 또는 포드를 다시 시작하지 않습니다.
사용 ReplicationController, ReplicaSet 및 배포 포드는 등의 웹 서버로, 종료 할 것으로 예상되지 않는다. ReplicationController는 restartPolicy 항상 포드에만 적용됩니다.
시스템 특정 시스템 서비스를 제공, DaemonSet 각 시스템에 대한 포드를 실행 사용합니다.
컨트롤러의 세 가지 유형은 PodTemplate을 포함한다. 그들이 직접 포드가 자신의 생성보다는, 포드를 만들 수 있도록 적절한 컨트롤러를 작성하는 것이 좋습니다. 자동 재생 시스템의 고장 및 제어기 캔의 경우에 포드를 분리 할 수있는 방법이 없기 때문이다.
클러스터의 나머지 노드 사망 또는 분리가의는 Kubernetes을 적용 할 경우 정책은 모든 포드 실패 위상 노드에서 설정을 잃게됩니다.
(8) livenessProbe의 해결
[루트 @의 K8S 마스터 ~] #의 kubectl이 pod.spec.containers.livenessProbe 설명
종류 : 포드
버전 : V1
자원 : livenessProbe <개체>
이러한 프로세스 (PS)을 검출하는 방법으로 Exec 명령
행의 여러 실패를 세 번을 검출하는 것은 기본적으로 실패로 간주됩니다 failureThreshold
얼마나 프로브 periodSeconds마다 10 초 기본적으로
초 timeoutSeconds 프로브 슈퍼마켓 1의 기본 수
initialDelaySeconds 초기화 지연 검출, 메인 프로그램의 완료 이후 처음의 검출이 시작되지 않을
검출 포트 tcpSocket 검출
httpGet HTTP 요청 감지
예를 들어 자원의 포드 유형의 유효화의 정의, 기본 이미지는 비지 박스 후이 배는 아 / tmp를 / 테스트 파일을 만드는 과정을 시작하고 삭제 한 다음 3,600초을 기다리는, 비지 박스입니다. 그런 가능성 검출 모드 방식 간부 명령 판정 행한다 정의 / TMP / 테스트가 존재, 즉 생존의 존재를 나타내고, 이는 용기의 부재가 걸려있다 나타낸다.
(9) 리소스 요구 사항과 자원 제약
부두 노동자의 맥락에서, 우리는 그 자원 요청 또는 컨테이너 제한의 운영에 소비 할 수 있습니다 알고 있습니다. 는 Kubernetes에서, 또한 동일한기구, 용기 있거나 포드를 적용 할 수 있고 CPU 및 메모리 자원에 의해 소비된다. CPU 자원 즉, 자원의 양이 수요에 계약을 체결 할 수 있으며, 압축 유형에 속한다. 메모리는 비 압축 형 자원에 속하는, 예상치 못한 문제가 발생할 수 있습니다 메모리를 축소.
자원의 분리는 현재 수준 컨테이너 구성 포드 사양 정의 필드 아래 용기 내에 CPU 및 메모리 자원을 필요로 속한다. 특정 필드는 "요청"자원의 요구 된 양 있도록 정의 할 수 있습니다. 그 용기는 자원의 양보다 적은 실행할 수 있지만, 너무 많은 자원 공급이 있음을 확인해야합니다. 그리고 "제한"하드 한계에 속하는 가능한 자원의 최대 한계입니다.
는 Kubernetes에서, CPU (1) 유닛 분획 측정 방법을 지원하는 물리적 머신 CPU에서 가상 머신의 가상 CPU (개 vCPU) 또는 하이퍼 스레딩에 대응 (마이크로 코어 1000 millicores에 대응하는 코어 (1core) ), 따라서 0.5 500m 코어, 즉, 1/2에 해당하는 코어. 메모리는 또한, E, P, T, G, M 및 K 접미사 유닛으로서, 또는 에이, 파이, 티타늄, 승기 미시간 기 및 다른 형태의 접미사 유닛 사용될 수있는 동일한 측정법 바이트 기본이며 .
예를 들어, 자원 요구 사항 :
apiVersion : V1
종류 : 포드
메타 데이터 :
이름 : nginx를 포드
투기:
용기 :
- 이름 : nginx를
이미지 : nginx를
자원:
요청 :
메모리 : "128Mi"
CPU : "200m"
형상 목록은 위의 nginx 요청 CPU 리소스의 크기는 CPU 코어는, 반드시 그러한 실제 동작을 사용하지 않는 것이 가능한 메모리 크기 128Mi 바람직이고 빠른 방법을 실행 Nginx에 충분하다는 것을 의미 200m이며 더 많은 자원. 메모리 자원의 유형을 고려, 가능성을 OOM 킬러 런타임의 존재에 지정된 크기를 초과 사망, 그래서 상한값을 통해 요청은 메모리 사용 속해됩니다.
예를 들어, 자원 제약 조건 :
컨테이너 자원은 컨테이너를 실행하는 데 필요한 최소한의 자원을 보장하기 위해에만 필요하지만 사용 가능한 자원의 상한을 제한하지 않습니다. 추가 속성을 필요로 시스템 자원의 장기적인 직업에이 버그 응용 프로그램뿐만 아니라 이어질 수는 컨테이너 정의 된 자원 사용의 최대 양을 제한합니다. CPU는 자유롭게 조정할 수 있습니다 압축 자원을 속한다. 메모리는 제한 속성은 메모리의 크기를 정의를 통해 할당하는 과정은, 포드 OOM 킬러가 살해 될 하드 제한 자원에 속한다. 다음과 같습니다 :
[루트 @의 K8S 마스터 ~] #의 정력 memleak-pod.yaml
apiVersion : V1
종류 : 포드
메타 데이터 :
이름 : memleak 포드
라벨 :
응용 프로그램 : memleak
투기:
용기 :
- 이름 : simmemleak
이미지 : saadali / simmemleak
자원:
요청 :
메모리 : "64Mi"
CPU : "1"
제한:
메모리 : "64Mi"
CPU : "1"
[루트 @의 K8S 마스터 ~] # 개의 kubectl -f memleak-pod.yaml 적용
포드 / memleak 포드가 생성
[루트 @의 K8S 마스터 ~] # kubectl GET 포드 -l 응용 프로그램 = memleak
NAME READY 상태는 나이를 다시 시작합니다
memleak 포드 0/1은 2 12S를 OOMKilled
[루트 @의 K8S 마스터 ~] # kubectl GET 포드 -l 응용 프로그램 = memleak
NAME READY 상태는 나이를 다시 시작합니다
memleak 언더 28S 2 0/1 CrashLoopBackOff
때문에 memleak 종단에서 메모리 제한의 항상에 대한 포드 기본 리소스를 다시 시작 정책은되는 포드가 OOM 킬러를 죽인 메모리 자원 고갈이 다시 시작 지연 다시 시작 Kunernetes 시스템을 실행할 것이기 때문에 각, 여러 번 반복됩니다 포인트, 즉시 다시 시작됩니다 "CrashLoopBackOff는"일반적으로 재부팅 시간 시간은 포드 상태 뒤에보고, 길게 나갈 것입니다.
또한는 Kubernetes 클러스터에 많은 실행 포드, 다음 리소스 노드가 포드를 사용하여 여러 개체를 충족 할 수없는 경우, 분명있을 필요가있다, 따라서 무엇인지 포드 객체를 종료하기 위해? ?
는 Kubernetes 자체 우선 순위의 우선 순위 객체 결정 포드 포드 종료의 도움의 필요성을 판단 할 수 없습니다. 요청과 목적에 따라 포드는 한계를 속성는 Kubernetes 포드는 세 가지 범주의 서비스 품질에 객체 :
보장 : 각 컨테이너는 요청 및 제한 CPU 및 메모리 자원 포드가 자동으로 가장 높은 우선 순위에 속하는이 범주에 속하는 대한 동일한 속성이 제공된다.
Burstable 적어도 하나의 용기에 요구 CPU 나 메모리 특성이 보장 하나의 카테고리는 카테고리, 중간 우선 순위에 의한 자원의 요건을 만족하지 않는 제공된다.
BestEffort : 컨테이너는 요청되지 않은 속성을하는 제공하고 가장 낮은 수준 사이에서 자동으로 카테고리에 기인 포드 자원 제한을, 속성입니다.