Hay dos casos de los que quiero escribir:
- Un browser consume un endpoint de una aplicacion nginx.
- Un cliente kubectl trata de crear un pod.
Caso 1:
[curl - cliente]
|
v
[DNS Publico]
|
v
[Load Balancer (externo)]
|
v
=== Worker Nodes ===
|
v
[Ingress Controller Pod]
|
v
[Service]
|
v
[Kube-Proxy (iptables/ipvs)]
|
v
[Pod (NGINX)]
|
v
[Container Runtime]
|
v
[NGINX]
En general todo funciona en el worker node, segun el servicio que se intenta consumir.
2. Crear un pod
[Usuario]
|
v
[Kubectl apply -f pod.yaml]
|
v
[Kubeconfig (token)]
|
v
==== Control plane ===
|
v
[Kube-ApiServer (Entrypoint)]
|
v
> Autenticacion (AuthN)
> Autorizacion (RBAC)
> Admission Controller
|
> Mutating
> Validating
|
v
[etcd] > Registrar el estado deseado
|
v
----- En desatendido
[kube-scheduler]
|
v
(observa pod sin nodename)
|
v
(Decide worker node adecuado)
|
v
[Kube-apiserver]
|
v
[etcd] Actualiza el node name
---- en desatendido
|
v
[kubecontroller-manager]
|
v
(asegura e lestado si viene de un deployment)
|
v
---- Worker node
|
v
[kubelet]
|
v
(Detecta pod asignado a este nodo)
|
v
[Container runtime (Containerd)]
|
v
(pull image desde registry)
|
v
(Crea contenedor)
|
v
[Pod en estado running]
|
v
[Kubelet reporta el estad]
|
v
====CONTROLPLANE===
|
v
[kube-apiserver]
|
v
[etcd (actualiza estado)
|
v
==== SALIDA
[kubectl]
Algunos puntos importantes.
KubeAPI server siempre recibe la señal primero.
el kubeapi server es el unico que contacta con ETCD
Pero en teoria cualquier componente del plano de control podria.
El kubescheduler asigna y evalua la solicitud.
El kubecontroller-manager la despacha.
El kubelet la ejecuta.
Al final de todo, cada accion se guarda en el etcd.