這篇文章主要講解了“如何保護(hù)Kubernetes Critical Pod”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“如何保護(hù)Kubernetes Critical Pod”吧！

成都創(chuàng)新互聯(lián)公司是一家專業(yè)提供鄰水企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站制作、成都做網(wǎng)站、H5開發(fā)、小程序制作等業(yè)務(wù)。10年已為鄰水眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進(jìn)行中。

Kubelet Eviction Manager Admit

kubelet在syncLoop中每個(gè)1s會循環(huán)調(diào)用syncLoopIteration，從config change channel | pleg channel | sync channel | houseKeeping channel | liveness manager's update channel中獲取event，然后分別調(diào)用對應(yīng)的event handler進(jìn)行處理。

• configCh: dispatch the pods for the config change to the appropriate handler callback for the event type

• plegCh: update the runtime cache; sync pod

• syncCh: sync all pods waiting for sync

• houseKeepingCh: trigger cleanup of pods

• liveness manager's update channel: sync pods that have failed or in which one or more containers have failed liveness checks

特別提一下，houseKeeping channel是每隔houseKeeping（10s）時(shí)間就會有event，然后執(zhí)行HandlePodCleanups，執(zhí)行以下清理操作：

• Stop the workers for no-longer existing pods.（每個(gè)pod對應(yīng)會有一個(gè)worker，也就是goruntine）

• killing unwanted pods

• removes the volumes of pods that should not be running and that have no containers running.

• Remove any orphaned mirror pods.

• Remove any cgroups in the hierarchy for pods that are no longer running.

pkg/kubelet/kubelet.go:1753

func (kl *Kubelet) syncLoopIteration(configCh <-chan kubetypes.PodUpdate, handler SyncHandler,
	syncCh <-chan time.Time, housekeepingCh <-chan time.Time, plegCh <-chan *pleg.PodLifecycleEvent) bool {
	select {
	case u, open := <-configCh:
		
		if !open {
			glog.Errorf("Update channel is closed. Exiting the sync loop.")
			return false
		}

		switch u.Op {
		case kubetypes.ADD:
			
			handler.HandlePodAdditions(u.Pods)
		...
		case kubetypes.RESTORE:
			glog.V(2).Infof("SyncLoop (RESTORE, %q): %q", u.Source, format.Pods(u.Pods))
			// These are pods restored from the checkpoint. Treat them as new
			// pods.
			handler.HandlePodAdditions(u.Pods)
		...
		}

		if u.Op != kubetypes.RESTORE {
			...
		}
	case e := <-plegCh:
		...
	case <-syncCh:
		...
	case update := <-kl.livenessManager.Updates():
		...
	case <-housekeepingCh:
		...
	}
	return true
}

syncLoopIteration中定義了當(dāng)kubelet配置變更重啟后的邏輯：kubelet會對正在running的Pods進(jìn)行Admission處理，Admission的結(jié)果有可能會讓該P(yáng)od被本節(jié)點(diǎn)拒絕。

HandlePodAdditions就是用來處理Kubelet ConficCh中的event的Handler。

// HandlePodAdditions is the callback in SyncHandler for pods being added from a config source.
func (kl *Kubelet) HandlePodAdditions(pods []*v1.Pod) {
	start := kl.clock.Now()
	sort.Sort(sliceutils.PodsByCreationTime(pods))
	for _, pod := range pods {
		...

		if !kl.podIsTerminated(pod) {
			...
			// Check if we can admit the pod; if not, reject it.
			if ok, reason, message := kl.canAdmitPod(activePods, pod); !ok {
				kl.rejectPod(pod, reason, message)
				continue
			}
		}
		...
	}
}

如果該P(yáng)od Status不是屬于Terminated，就調(diào)用canAdmitPod對該P(yáng)od進(jìn)行準(zhǔn)入檢查。如果準(zhǔn)入檢查結(jié)果表示該P(yáng)od被拒絕，那么就會將該P(yáng)od Phase設(shè)置為Failed。

pkg/kubelet/kubelet.go:1643

func (kl *Kubelet) canAdmitPod(pods []*v1.Pod, pod *v1.Pod) (bool, string, string) {
	// the kubelet will invoke each pod admit handler in sequence
	// if any handler rejects, the pod is rejected.
	// TODO: move out of disk check into a pod admitter
	// TODO: out of resource eviction should have a pod admitter call-out
	attrs := &lifecycle.PodAdmitAttributes{Pod: pod, OtherPods: pods}
	for _, podAdmitHandler := range kl.admitHandlers {
		if result := podAdmitHandler.Admit(attrs); !result.Admit {
			return false, result.Reason, result.Message
		}
	}

	return true, "", ""
}

canAdmitPod就會調(diào)用kubelet啟動時(shí)注冊的一系列admitHandlers對該P(yáng)od進(jìn)行準(zhǔn)入檢查，其中就包括kubelet eviction manager對應(yīng)的admitHandle。

pkg/kubelet/eviction/eviction_manager.go:123

// Admit rejects a pod if its not safe to admit for node stability.
func (m *managerImpl) Admit(attrs *lifecycle.PodAdmitAttributes) lifecycle.PodAdmitResult {
	m.RLock()
	defer m.RUnlock()
	if len(m.nodeConditions) == 0 {
		return lifecycle.PodAdmitResult{Admit: true}
	}
	
	if utilfeature.DefaultFeatureGate.Enabled(features.ExperimentalCriticalPodAnnotation) && kubelettypes.IsCriticalPod(attrs.Pod) {
		return lifecycle.PodAdmitResult{Admit: true}
	}

	if hasNodeCondition(m.nodeConditions, v1.NodeMemoryPressure) {
		notBestEffort := v1.PodQOSBestEffort != v1qos.GetPodQOS(attrs.Pod)
		if notBestEffort {
			return lifecycle.PodAdmitResult{Admit: true}
		}
	}

		return lifecycle.PodAdmitResult{
		Admit:   false,
		Reason:  reason,
		Message: fmt.Sprintf(message, m.nodeConditions),
	}
}

eviction manager的Admit的邏輯如下：

• 如果該node的Conditions為空，則Admit成功；

• 如果enable了ExperimentalCriticalPodAnnotation Feature Gate，并且該P(yáng)od是Critical Pod（Pod有Critical的Annotation，或者Pod的優(yōu)先級不小于SystemCriticalPriority），則Admit成功；

• SystemCriticalPriority的值為2 billion。

• 如果該node的Condition為Memory Pressure，并且Pod QoS為非best-effort，則Admit成功；

• 其他情況都表示Admit失敗，即不允許該P(yáng)od在該node上Running。

Kubelet Eviction Manager SyncLoop

另外，在kubelet eviction manager的syncLoop中，也會對Critical Pod有特殊處理，代碼如下。

pkg/kubelet/eviction/eviction_manager.go:226

// synchronize is the main control loop that enforces eviction thresholds.
// Returns the pod that was killed, or nil if no pod was killed.
func (m *managerImpl) synchronize(diskInfoProvider DiskInfoProvider, podFunc ActivePodsFunc) []*v1.Pod {
	...

	// we kill at most a single pod during each eviction interval
	for i := range activePods {
		pod := activePods[i]
		
		if utilfeature.DefaultFeatureGate.Enabled(features.ExperimentalCriticalPodAnnotation) &&
			kubelettypes.IsCriticalPod(pod) && kubepod.IsStaticPod(pod) {
			continue
		}
		...
		return []*v1.Pod{pod}
	}
	glog.Infof("eviction manager: unable to evict any pods from the node")
	return nil
}

當(dāng)觸發(fā)了kubelet evict pod時(shí)，如果該pod滿足以下所有條件時(shí)，將不會被kubelet eviction manager kill掉。

• 該P(yáng)od Status不是Terminated；

• Enable ExperimentalCriticalPodAnnotation Feature Gate；

• 該P(yáng)od是Critical Pod；

• 該P(yáng)od時(shí)Static Pod；

感謝各位的閱讀，以上就是“如何保護(hù)Kubernetes Critical Pod”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對如何保護(hù)Kubernetes Critical Pod這一問題有了更深刻的體會，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！

分享名稱：如何保護(hù)KubernetesCriticalPod
文章轉(zhuǎn)載：http://aaarwkj.com/article24/peseje.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊、ChatGPT、品牌網(wǎng)站制作、App設(shè)計(jì)、品牌網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)