Источник кубелета доступен здесь .
Kubelet может получить конфигурации Pod, требуемые локальным узлом, несколькими способами. Самый важный способ - Apiserver . Kubelet также может получить конфигурации Pod, указав каталог файлов или получив доступ к указанному HTTP-порту.
При запуске Kubelet создается объект PodConfig
.
Код kubernetes / blob / master / pkg / kubelet / config / config.go # L58 :
type PodConfig struct {
pods *podStorage
mux *config.Mux
// the channel of denormalized changes passed to listeners
updates chan kubetypes.PodUpdate
...
}
PodConfig
по сути является мультиплексором конфигураций Pod. Встроенный mux
может прослушивать источники различных конфигураций Pod (включая apiserver, file и http) и периодически синхронизировать состояние конфигурации Pod источников.
Код kubernetes / blob / master / pkg / kubelet / types / pod_update.go # L80 :
type PodUpdate struct {
Pods []*v1.Pod
Op PodOperation
Source string
}
Op
определяет тип смены Pod. Например, это могут быть значения типа ADD
или REMOVE
. В конце концов все типы PodUpdate
будут введены в updates
из podConfig
. Поэтому для прослушивания обновлений конфигурации Pod локального узла требуется только прослушивание канала update
.
После завершения запуска Kubelet выполняется функция syncLoop
.
Код kubernetes / blob / master / pkg / kubelet / kubelet.go # L180 :
// syncLoop is the main loop for processing changes. It watches for changes from
// three channels (file, apiserver, and http) and creates a union of them. For
// any new change seen, will run a sync against desired state and running state. If
// no changes are seen to the configuration, will synchronize the last known desired
// state every sync-frequency seconds. Never returns.
func (kl *Kubelet) syncLoop(updates <-chan kubetypes.PodUpdate, handler SyncHandler) {
...
for {
...
if !kl.syncLoopIteration(updates, handler, syncTicker.C, housekeepingTicker.C, plegCh) {
break
}
...
}
Весь процесс подробно описан в следующей статье: Понимание фрейма выполнения Kubelet Core .