Plan de IMPLEMENTACION
Generalmente existen tres soluciones de implementación para la alta disponibilidad maestra de Kubernetes:
1. Instalación de alta disponibilidad de kubeadm Utilice la herramienta kubeadm para instalar el clúster de Kubernetes. Implemente una alta disponibilidad del maestro aumentando la cantidad de nodos maestros y especificando VIP.
Los pasos específicos son los siguientes:
- Instalar un nodo maestro y dos nodos maestros de respaldo (completado por kubeadm)
- Configurar vip (usa herramientas como keepalived o haproxy)
- Especifique el parámetro apiserver-vip cuando kubeadm se une (kubeadm se une... --apiserver-advertise-address apiserver-vip)
- Cada nodo apiserver configura el parámetro service-cluster-ip-range y apunta a VIP. Esta solución es simple y fácil de implementar. kubeadm ayuda a completar las configuraciones más complejas, pero el plano de control tiene poca escalabilidad y confiabilidad depende del front-end VIP productos.
2. La alta disponibilidad del clúster etcd + apiserver utiliza el clúster etcd como almacenamiento de back-end, implementa múltiples instancias de apiserver y realiza LB para lograr una alta disponibilidad.
Los pasos específicos son los siguientes:
- Implementar clúster etcd (3 o 5 nodos)
- Varios nodos maestros implementan un servidor respectivamente, apuntando al clúster etcd.
- Utilice un servidor de proxy inverso LB (como nginx) para lograr el equilibrio de carga. Esta solución tiene buena escalabilidad y alta disponibilidad del plano de control, pero la implementación y configuración son complicadas y dependen de dispositivos LB adicionales.
3. Utilice CSKU (Kubernetes versión empresarial) para utilizar la versión empresarial Kubernetes (como GKE), que viene con una implementación maestra de alta disponibilidad. Al seleccionar la cantidad de nodos maestros y funciones de alta disponibilidad en la consola de GKE, GKE completará automáticamente la siguiente configuración:
- Implementar clúster etcd
- Implementar múltiples copias maestras
- Implementar el equilibrio de carga del servidor a través de LB incorporado es la solución más simple. Está completamente implementado y operado por la plataforma Kubernetes de versión empresarial, pero el costo es relativamente alto.
Aquí presentaré las dos primeras implementaciones.
método uno
1. Prepare 3 máquinas y configure nombres de host y hosts
maestro1
maestro2
maestro3
Edite /etc/hosts de todos los nodos y agregue mapeo de tres nodos:
192.168.0.1 maestro1
192.168.0.2 maestro2
192.168.0.3 maestro3
2. Instale kubeadm, kubelet y kubectl en todos los nodos maestros.
instalación adecuada -y kubeadm kubelet kubectl
3. Especifique VIP (como 10.0.0.10), use la configuración keepalived en master1 y configure la copia de seguridad keepalived en otros nodos maestros.
maestro1:
vrrp_instance VI_1 { estado MAESTRO interfaz ens4 virtual_router_id 50 prioridad 100 advert_int 1 autenticación { auth_type PASS auth_pass 1111 } virtual_ipaddress { 10.0.0.10 } }
Otros nodos maestros:
vrrp_instance VI_1 { estado BACKUP interfaz ens4 virtual_router_id 50 prioridad 50 advert_int 1 autenticación { auth_type PASS auth_pass 1111 } virtual_ipaddress { 10.0.0.10 } }
4. Inicialice los archivos de configuración de kubeadm en todos los nodos
configuración de kubeadm imprimir valores predeterminados de inicio> kubeadm.yaml
Modifique kubeadm.yaml y especifique la dirección del apiserver como vip:
apiVersion: kubeadm.k8s.io/v1beta2
tipo: InitConfiguration
localAPIEEndpoint:
publicidadDirección: "10.0.0.10"
5. Ejecute kubeadm init en el nodo master1 y use --config para especificar el archivo kubeadm.yaml.
inicio de kubeadm --config=kubeadm.yaml
6. Ejecute kubeadm join en otros nodos maestros y también especifique apiserver-vip.
kubeadm join 10.0.0.10:6443 --token abcdef.0123456789abcdef \ --discovery-token-ca-cert-hash sha256:1234..cdef --apiserver-advertise-address=10.0.0.10
7. Copie el archivo kubeconfig del nodo maestro a otros nodos. ¡En este punto, el clúster maestro de alta disponibilidad de Kubernetes implementado con la herramienta kubeadm se ha completado! El cliente solo necesita acceder a vip (10.0.0.10) y keepalived lo hará. reenvía automáticamente la solicitud al nodo maestro disponible.
En este punto, el clúster maestro de alta disponibilidad de Kubernetes implementado con la herramienta kubeadm se ha completado. El cliente solo necesita acceder a VIP (10.0.0.10) y keepalived reenviará automáticamente la solicitud al nodo maestro disponible. Esta solución es simple y fácil de implementar, pero su escalabilidad y confiabilidad son ligeramente deficientes y depende de software de terceros (como keepalived) para implementar LB y VIP. Pero es suficiente para probar y experimentar Kubernetes HA.
Método 2
1. Prepare 3 máquinas como clúster etcd:
- etcd1:10.0.0.11
- etcd2:10.0.0.12
- etcd3:10.0.0.13
2. Implementar etcd en etcd1
etcd --name etcd1 \
--listen-client-urls https://10.0.0.11:2379 \
--advertise-client-urls https://10.0.0.11:2379 \
--listen-peer-urls https:/ /10.0.0.11:2380 \
--initial-advertise-peer-urls https://10.0.0.11:2380 \
--initial-cluster etcd1=https://10.0.0.11:2380,etcd2=https://10.0 .0.12:2380,etcd3=https://10.0.0.13:2380 \
--initial-cluster-token etcd-token
3. Inicie también etcd en los nodos etcd2 y etcd3. El comando es el mismo que etcd1, excepto que el nombre y la dirección son diferentes.
4. Prepare 3 nodos maestros: master1, master2, master3
5. Instale kube-apiserver, kube-controller-manager y kube-scheduler en todos los nodos maestros
6. Configurar kube-apiserver
- --etcd-servers: especifica la dirección del clúster etcd
- --service-cluster-ip-range: especifique el rango de direcciones IP del clúster
- --secure-port: puerto apiserver (como 6443)
- Para otros parámetros, consulte el [documento de configuración de kube-apiserver] ( kube-apiserver | Kubernetes )
ejemplo maestro1:
kube-apiserver --etcd-servers=https://10.0.0.11:2379,https://10.0.0.12:2379,https://10.0.0.13:2379 --service-cluster-ip-range=10.0. 0.0/24 --secure-port=6443 -bind-address=10.0.0.11 ...
master2, master3... son similares, modifique la dirección de enlace a la IP del nodo correspondiente
7. Configure un proxy inverso (como nginx) para implementar el equilibrio de carga de alta disponibilidad de kube-apiserver
kube-apiserver ascendente {
servidor 10.0.0.11:6443;
servidor 10.0.0.12:6443;
servidor 10.0.0.13:6443;
}
servidor { escuchar 6443; proxy_pass http://kube-apserver; }
8. Otros componentes maestros se conectan al puerto 6443 de nginx.
Todos los nodos maestros:
kube-controller-manager --master=http://10.0.0.11:6443 ...
kube-scheduler --master=http://10.0.0.11:6443 ...
9. El nodo kubelet se conecta al puerto nginx 6443
10. El cliente kubectl también se conecta al puerto 6443 de nginx, logrando un plano de control multimaestro de alta disponibilidad con alta escalabilidad y alta disponibilidad. Como almacenamiento de claves de Kubernetes, etcd también tiene alta disponibilidad, y nginx implementa LB simple y confiable.
Esta solución tiene un diseño más complejo, pero más flexible y fiable. Adecuado para clústeres de Kubernetes a nivel de producto a gran escala, los nodos apiserver y etcd se pueden expandir según sea necesario. También es el modo clásico para la implementación real del plano de control de Kubernetes.
Acceder al modo de clúster
Hay varias formas de acceder a los clústeres de alta disponibilidad de Kubernetes:
1. El cliente kubectl se conecta al puerto 6443 de nginx y nginx reenviará automáticamente la solicitud a la instancia de kube-apiserver disponible.
Entonces, solo necesitas apuntar kubectl al puerto 6443 de cualquier nodo maestro:
kubectl --server=https://10.0.0.11:6443 obtener nodos
2. El punto final del servidor API expuesto al mundo exterior también es el puerto 6443 de nginx, por lo que llamar a la API de Kubernetes puede ser así:
rizo https://10.0.0.11:6443/api/v1/nodes
3. DNS está dentro del clúster de Kubernetes. Kube-dns resolverá kubernetes.default.svc.cluster.local en el puerto 6443 de nginx.
Por lo tanto, los pods del clúster también pueden acceder al servidor API a través de este nombre DNS.
4. El servicio puede crear un servicio de Kubernetes en el clúster, configurar el tipo en NodePort o LoadBalancer, abrir el puerto 6443 y proporcionar acceso al mundo exterior.
Por ejemplo:
yaml
apiVersion: v1 tipo: Metadatos
del servicio : nombre: kubernetes especificación: tipo: NodePort puertos: - puerto: 6443 targetPort: 6443 protocolo: selector TCP: componente: apiserver
Una vez creado el servicio, el mundo exterior puede acceder a él a través de CUALQUIER IP de Node: puerto 31643 (31643 es un puerto asignado aleatoriamente).
Los anteriores son varios métodos para acceder a los clústeres de alta disponibilidad de Kubernetes. En términos generales, puede usar el nombre de dominio del servicio Kubernetes directamente internamente (recomendado); externamente puede llamar a la API a través del servicio NodePort o directamente a través del puerto 6443 de nginx (adecuado para pruebas).
En el uso diario, la herramienta de línea de comandos kubectl es el método más utilizado. Solo necesita instalar kubectl en cada nodo y especificar la dirección de apiserver correcta a usar.
Extensiones relacionadas
mantener vivo
Lo más importante aquí es la IP virtual VRRP. La IP virtual VRRP (IP virtual del protocolo de redundancia del enrutador virtual) es un concepto clave para que keepalived logre una alta disponibilidad.
Es una dirección IP flotante que puede oscilar entre el nodo maestro y el nodo de respaldo en el clúster keepalived. El cliente no se conecta directamente al nodo principal o al nodo de respaldo, sino a esta IP virtual.
Cuando el nodo principal falla, la IP virtual VRRP se desplazará del nodo principal al nodo de respaldo y la dirección IP conectada por el cliente permanecerá sin cambios, lo que permite la conmutación por error del negocio. La IP virtual VRRP tiene las siguientes características:
1. Es una IP lógica y no corresponde a la dirección IP física del nodo principal o del nodo de respaldo.
2. Pasará entre el nodo maestro keepalived y el nodo de respaldo para lograr una alta disponibilidad.
3. El cliente solo presta atención a la IP virtual VRRP y no necesita preocuparse por la dirección IP física del nodo principal o del nodo de respaldo.
4. La dirección MAC de la IP virtual VRRP cambiará a medida que la IP cambie y el conmutador actualizará la tabla MAC sin intervención manual.
5. Una instancia de VRRP puede tener varias IP virtuales de VRRP y todas las IP virtuales cambiarán al mismo tiempo.
6. La subred donde se encuentra la IP virtual VRRP debe configurarse en las tarjetas de red del nodo principal y del nodo de respaldo.
La IP virtual VRRP es la piedra angular de la implementación de alta disponibilidad de keepalived. Cuando falla el nodo maestro, implementa una conmutación perfecta con el nodo de respaldo, proporciona una IP de entrada flotante lógica para el cliente e implementa automáticamente la conmutación por error. Este es también el núcleo de la Protocolo VRRP intención original.
En resumen, las principales funciones de la IP virtual VRRP son:
- Proporcionar una IP de entrada lógica para el cliente.
- Implementar conmutación por error con el nodo en espera.
- Ocultar las direcciones IP físicas del nodo maestro del clúster y del nodo de respaldo.
- Configuración de cliente simplificada
camino ngnix
Todo el mundo está familiarizado con nginx, un servidor proxy inverso que expone un puerto y equilibra la carga de todas las direcciones del nodo maestro según el contexto.
kubectl
kubectl es el comando del cliente de solicitud de k8s. El comando kubectl encapsula una solicitud http tranquila basada en la información de parámetros en el comando y envía la solicitud a kube-apiserver. A continuación, enumere las solicitudes correspondientes a las solicitudes http reales de varios comandos:
Obtenga la lista de pods:
OBTENER /api/v1/namespaces/{namespace}/pods
Crear grupo:
POST /api/v1/namespaces/{namespace}/pods
Obtenga la lista de servicios:
OBTENER /api/v1/namespaces/{namespace}/services
Crear servicio:
POST /api/v1/namespaces/{namespace}/services
Obtenga la lista de implementación:
OBTENER /apis/apps/v1/namespaces/{namespace}/deployments
Crear despliegue:
POST /apis/apps/v1/namespaces/{namespace}/deployments
Obtenga la lista de nodos:
OBTENER /api/v1/nodos
Obtenga la lista de espacios de nombres:
OBTENER /api/v1/espacios de nombres
Crear espacio de nombres:
POST /api/v1/espacios de nombres
Obtenga la lista secreta:
OBTENER /api/v1/namespaces/{namespace}/secrets
Crear secreto:
POST /api/v1/namespaces/{namespace}/secretos
Obtenga la lista de ConfigMap:
OBTENER /api/v1/namespaces/{namespace}/configmaps
Crear mapa de configuración:
POST /api/v1/namespaces/{namespace}/configmaps
Ejecute el ejecutivo de kubectl:
POST /api/v1/namespaces/{namespace}/pods/{pod}/exec
Ejecute el comando aplicar o crear del archivo yaml
curl -X POST -H "Tipo de contenido: aplicación/json" -H "Autorización: Portador $TOKEN" -d '{"apiVersion":"v1", "kind":"Pod"...}' https: //10.0.0.1:6443/api/v1/namespaces/default/pods
Estas son solo algunas de las API comunes. Hay muchas más API encapsuladas por kubectl. Interactúa con el servidor API de Kubernetes en un estilo API RESTful mediante la construcción de diferentes solicitudes HTTP para realizar todas las funciones de kubectl.