Kubernetes: 컨테이너 시작 전 구성 요소 프로세스
11397 단어 kubernetes
kubectl create -f x.yaml
에서 우리는 복제 컨트롤러를 만들고 용기가 시작될 때까지 모든 구성 요소가 어떻게 작동하는지 정리했다.Kubernetes1.2의 정보입니다.각 구성 요소에 대한 개요는 Kubernetes: 구성 요소 목록 구성 를 참조하십시오.시퀀스 맵
각 구성 요소는 API 서버의 리소스를 모니터링하고 비동기적으로 실행하므로 실제 액세스 방향은 구성 요소에서 API 서버로 변경됩니다.
kubectlcreate를 사용하여 복제 컨트롤러 만들기
kubectl create -f x.yaml
에서 복제 컨트롤러를 생성할 때 내부적으로 API 서버의 POST /api/v1/namespaces/{namespace}/replicationcontrollers API를 켜서 복제 컨트롤러 정보를 자체 검사합니다.API 서버에서 복제 디렉터 리소스를 생성하는 단계(컨테이너가 시작되지 않음) 표시 완료created
.yaml과 json 형식의 파일을 동시에 지정할 수 있지만, 내부 대상으로 전환하고 검증을 진행하면, 컴퓨터를 켜서 자체 검사할 때 파일을 JSON 형식으로 인코딩합니다.
다음 옵션
--v
을 사용하여 로그 수준을 지정하면 로그에서 API에 대한 액세스를 추적할 수 있습니다.$ kubectl create --v=10 -f frontend-controller.yaml
API 서버 처리
API 서버는 모든 구성 요소에서 자원 정보를 수신하여 etcd에 저장합니다.리소스 정보만 관리하고 API 서버는 Node 또는 controller를 직접 명령하지 않습니다.각 구성 요소는 API 서버의 리소스를 모니터링하므로 비동기적으로 이벤트를 전달합니다.
제어 프로그램 처리
kube-controller-manager의 시작 컨트롤러는 복제 컨트롤러를 관리하는 데 사용되는 복제 관리자입니다.(복잡하지만 리소스 이름인 복제 컨트롤러)
Replication Manager는 API 서버의 GET /api/v1/watch/replicationcontrollers, GET /api/v1/watch/pods를 사용하여 Replication Controller 및pod 리소스의 변경 사항을 모니터링합니다.
Replication Manager의 작업은 지정한 Replica 수와 활동pod 수의 차이를 계산하여 부족하거나 남은 Pod을 생성, 삭제하여 조정하는 것입니다.
따라서 새로운 복제 컨트롤러를 만들 때 API 서버의 POST /api/v1/namespaces/{namespace}/pods를 사용하여pod수분의replica수를 생성합니다.이 경우 Pod을 모든 노드에 할당하지 않고 리소스로만 사용할 수 있습니다.
참조: 활성 Pod 기준
pkg/controller/controller_utils.go
func IsPodActive(p api.Pod) bool {
return api.PodSucceeded != p.Status.Phase &&
api.PodFailed != p.Status.Phase &&
p.DeletionTimestamp == nil
}
처리 scheduler
스케줄러는 API 서버의 GET /api/v1/pods 를 사용하여 노드에 할당되지 않은 Pod (할당된 Pod) 를 모니터링합니다.이 API의 매개 변수
fieldSelector
는 Pod의field에 조건을 추가하고 이 매개 변수를 사용하여 할당되지 않은, 할당된 Pod을 지정할 수 있습니다.할당되지 않은 Pod은 NodeSelector 등의 조건과 우선 순위에 따라 Node를 선택하고 API 서버의 POST /api/v1/namespaces/{namespace}/bindings 를 사용하여 Node 할당(Binding)을 수행합니다.
(참조: plugin/pkg/scheduler/generic_scheduler.go
참고: Pod이 할당되지 않은 선택 기준
pkg/scheduler/factory/factory.go
// Returns a cache.ListWatch that finds all pods that need to be
// scheduled.
func (factory *ConfigFactory) createUnassignedNonTerminatedPodLW() *cache.ListWatch {
selector := fields.ParseSelectorOrDie("spec.nodeName==" + "" + ",status.phase!=" + string(api.PodSucceeded) + ",status.phase!=" + string(api.PodFailed))
return cache.NewListWatchFromClient(factory.Client, "pods", api.NamespaceAll, selector)
}
참조: 자동 연결 검사 켜기 예{
"kind": "Binding",
"apiVersion": "v1",
"metadata": {
"name": "frontend-yai9k",
"namespace": "default",
"creationTimestamp": null
},
"target": {
"kind": "Node",
"name": "172.17.4.99"
}
}
Kubelet
kubelet은 API 서버의 GET /api/v1/pods 모니터링을 사용하여 자체 노드에 할당된 Pod
fieldSelector
매개 변수 노드 이름을 감시합니다.그리고 Pod에 정의된 용기docker를 시작합니다. (rkt도 선택할 수 있습니다.)PUT /api/v1/namespaces/{namespace}/pods/{name}/status를 통해 Pending, Running 등의 Pod 상태를 업데이트합니다.또한 를 사용하여 Node 자체의 정보를 주기적으로 업데이트합니다(기본값은 10초입니다.kubelet의
PUT /api/v1/nodes/{name}/status
옵션을 통해 지정할 수 있습니다.참조: 노드에 할당된 점 선택
pkg/kubelet/config/apiserver.go
func NewSourceApiserver(c *clientset.Clientset, nodeName string, updates chan<- interface{}) {
// spec.nodeNameが自Nodeのものを選択してwatch
lw := cache.NewListWatchFromClient(c.CoreClient, "pods", api.NamespaceAll, fields.OneTermEqualSelector(api.PodHostField, nodeName))
newSourceApiserverFromLW(lw, updates)
}
Docker, rkt
쿠벨렛은 쿠벨렛 시작 옵션
--node-status-update-frequency
에서 지정한 용기가 실행될 때 할당된 Pod 용기를 시작합니다(기본값은 Docker입니다.--container-runtime도 선택할 수 있습니다.이곳에서 실제 컨테이너가 마침내 가동되었다.Docker의 경우rkt 공유 네트워크 이름 공간을 유지하는 메커니즘으로 함께 시작됩니다.참조: Kubernetes 구성 요소 로그
Kubernetes의 구성 요소 공통 로그 라이브러리 사용자 컨테이너.모든 구성 요소
--v
옵션은 내부 동작을 볼 수 있도록 로그 수준을 지정할 수 있습니다.코드에 사용되는 최대 로그 레벨은 10
Reference
이 문제에 관하여(Kubernetes: 컨테이너 시작 전 구성 요소 프로세스), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/tkusumi/items/346d41a6240590b899cd텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)