Cómo verificar la información de actualización de Kubernetes

Primero echemos un vistazo a algunos conceptos y la arquitectura básica de Kubernetes en su conjunto, y luego le brindaremos una breve descripción general de la red, la administración de recursos, el almacenamiento, el descubrimiento de servicios, el equilibrio de carga, la alta disponibilidad y la actualización continua. , seguridad, monitoreo, etc. Presentamos estas características principales de Kubernetes. Por supuesto, también habrá algunas cuestiones que requerirán atención. El objetivo principal es ayudar a todos a comprender rápidamente las funciones principales de Kubernetes y brindar referencia y ayuda al estudiar y utilizar esta herramienta en el futuro. 1. Algunos conceptos de Kubernetes: los usuarios no necesitan preocuparse por cuántas máquinas necesitan, solo por el entorno necesario para que se ejecute el software (servicio). Con el servicio como centro, lo que debe preocuparle es la API, cómo dividir servicios grandes en servicios pequeños y cómo utilizar la API para integrarlos. Asegúrese de que el sistema siempre funcione según el estado especificado por el usuario. No solo le proporciona servicios de contenedor, sino que también proporciona una forma de actualizar el sistema de software manteniendo HA es la función que muchos usuarios más desean y también la más difícil de lograr. Cosas de las que preocuparse y cosas de las que no preocuparse. Apoyar mejor el concepto de microservicio, dividir y subdividir los límites entre servicios, como la introducción de conceptos como etiqueta y pod. Para conocer la arquitectura de Kubernetes, puede consultar la documentación oficial. Se compone aproximadamente de algunos componentes principales, incluidos kube-apiserver, kube-scheduler, kube-controller-manager en el nodo maestro, componente de control kubectl, almacenamiento de estado, etc., kubelet y kube-proxy en el nodo esclavo y soporte de red subyacente. (Puedes usar franela, OpenVSwitch, Weave, etc.). Parece ser un diseño de arquitectura de microservicio, pero actualmente no admite el escalado horizontal de un solo servicio, pero esto se solucionará en futuras versiones de Kubernetes. 2. Se le presentarán brevemente las características principales de Kubernetes desde los aspectos de red, descubrimiento de servicios, equilibrio de carga, administración de recursos, alta disponibilidad, almacenamiento, seguridad, monitoreo, etc. - gt; hazlo más simple. Además, los amigos interesados ​​pueden obtener más información sobre el descubrimiento de servicios, la alta disponibilidad y el monitoreo a través de este artículo. 1) Red El método de red de Kubernetes resuelve principalmente los siguientes problemas: a. La comunicación entre contenedores estrechamente acoplados se resuelve mediante el acceso Pod y localhost. b Comunicarse entre Pods y establecer subredes de comunicación, como túneles, enrutamiento, franela, OpenvSwitch y Weave. c. La comunicación entre el Pod y el Servicio, así como el sistema externo y el Servicio, se resuelve mediante la introducción del Servicio. La red Kubernetes asigna una dirección IP a cada Pod. No es necesario establecer enlaces entre Pods y, básicamente, no es necesario lidiar con el mapeo de puertos entre contenedores y hosts. Nota: Después de reconstruir el Pod, la IP se reasignará, por lo que la comunicación de la intranet no debe depender del PodIP para usar variables de entorno del Servicio o DNS para resolver el problema. 2) Descubrimiento de servicios y equilibrio de carga kube-proxy y DNS Antes de v1, el Servicio contenía los campos portalip y publicIP, que especificaban respectivamente la IP virtual del servicio y la IP de la máquina de exportación del servicio se puede especificar arbitrariamente para incluir cualquiera. kube-proxy en el clúster Puede haber varios nodos. portalIp salta a la dirección de intranet del contenedor a través de NAT.

En la versión v1, publicIPS fue abolido por acuerdo y marcado como PublicIPs obsoleto solo por compatibilidad con versiones anteriores. PortalIp también se cambió a ClusterIp en la lista de definición de puerto de servicio, se agregó un elemento nodePort, que corresponde al puerto de servicio asignado en el nodo. El servicio DNS está en modo complementario y es necesario instalar skydns y kube2dns. kube2dns obtendrá la IP del clúster y la información del puerto del servicio leyendo la API de Kubernetes y, al mismo tiempo, verificará los cambios del servicio en forma de vigilancia, recopilará la información de cambios a tiempo y enviará la información de IP a etcd para su archivo. , mientras que skydns registra la información a través de DNS en etcd. Abra el puerto 53 para proporcionar servicios externos. El registro de nombre de dominio DNS aproximado es nombre de servicio.espacio de nombres.tenx.dominio, y "tenx.dominio" es el nombre de dominio principal establecido de antemano. Nota: kube-proxy puede tener problemas de rendimiento de acceso cuando la escala del clúster aumenta. Puede considerar reemplazarlo con otros métodos, como HAProxy, que redirige directamente el tráfico a los puntos finales del servicio o Pods. Los funcionarios de Kubernetes también están solucionando este problema. 3) Gestión de recursos Hay tres niveles de métodos de restricción de recursos, a saber, en los niveles de contenedor, pod y espacio de nombres. El nivel de contenedor utiliza principalmente el soporte del contenedor en sí, como el soporte de Docker para CPU, memoria, disco, red, etc., el aspecto Pod puede limitar el rango de recursos para crear Pods en el sistema, como la CPU máxima o mínima; y los requisitos de memoria; el nivel de espacio de nombres es para los usuarios. Los límites de recursos de nivel, incluida la CPU, la memoria y la cantidad de Pods, rc y servicios, también pueden ser limitados. Modelo de gestión de recursos: "Simple, universal, preciso y escalable. El cálculo actual de la asignación de recursos también es relativamente simple. No existen funciones poderosas como la preferencia de recursos. A través de la cantidad total de recursos en cada nodo y los diversos recursos que se han utilizado, la suma ponderada se utiliza para calcular a qué nodos se asigna primero un determinado Pod. Aún no ha incluido la evaluación de los recursos reales disponibles de los nodos y requiere su propio complemento de programación para admitirlo. De hecho, Kubelet ya puede obtener los recursos del nodo. Solo necesita recopilarlos y calcularlos. Creo que las versiones posteriores de Kubernetes lo admitirán. 4) Alta disponibilidad Se refiere principalmente al método HA del nodo maestro. La recomendación oficial es utilizar etcd para implementar la elección de maestro. Obtenga un kube-apiserver de varios maestros para garantizar que al menos un maestro esté disponible para lograr una alta disponibilidad. El acceso externo se proporciona en forma de balanceador de carga. Este método se puede utilizar como ha, pero aún no está maduro. Se entiende que la función de ha se actualizará y mejorará en el futuro. Una imagen ayuda a todos a comprender: es decir, en el contexto del clúster etcd, hay varios kube-apiserver y pod-master se usa para garantizar que solo el maestro principal esté disponible. Al mismo tiempo, hay varios kube-sheduller y kube-controller-manager, y solo se puede ejecutar un conjunto de kube-apiserver al mismo tiempo. 5) actualización continua El diseño de RC desde el principio fue facilitar la actualización continua, reemplazando los Pods uno por uno para actualizar el servicio y minimizar el tiempo de interrupción del servicio. La idea básica es crear un nuevo rc con una réplica de 1, reducir gradualmente las réplicas del antiguo rc, aumentar las réplicas del nuevo rc y eliminar el antiguo rc cuando el número llegue a 0. Proporcionado por kubectl, puede especificar la imagen actualizada, el intervalo de tiempo para reemplazar los pods y también puede revertir la operación de actualización que se está ejecutando actualmente.

De manera similar, Kuberntes también admite la implementación simultánea de múltiples versiones y las distingue mediante etiquetas. Mientras el servicio permanece sin cambios, los Pods que respaldan el servicio se pueden ajustar y las condiciones de trabajo de los nuevos Pods se pueden probar y monitorear. 6) Almacenamiento Todo el mundo sabe que el contenedor en sí generalmente no conserva datos. En Kubernetes, si el contenedor sale de forma anormal, kubelet simplemente reinicia un nuevo contenedor basado en la imagen original. Además, si ejecutamos varios contenedores en el mismo Pod, a menudo necesitamos compartir algunos datos entre estos contenedores. El volumen de Kuberenetes se utiliza principalmente para resolver los dos problemas básicos anteriores. Docker también tiene el concepto de Volumen, pero es relativamente simple y el soporte actual es muy limitado. Kubernetes tiene una definición clara y un amplio soporte para Volumen. El concepto central: el volumen es solo un directorio y todos los contenedores en el mismo Pod pueden acceder a él. El aspecto de este directorio, los medios que se utilizarán en el backend y su contenido estarán determinados por el tipo de volumen específico utilizado. Crear un pod con volumen: spec.volumes especifica la información de volumen requerida por este pod spec.containers.volumeMounts especifica qué contenedores deben usar este volumen. Kubernetes admite el volumen de manera muy amplia y muchos contribuyentes le agregan soporte de almacenamiento diferente. la comunidad de Kubernetes. EmptyDir se elimina con el Pod. Es adecuado para almacenamiento temporal, recuperación ante desastres y datos de tiempo de ejecución compartidos. Admite filesystemhostPath respaldado por RAM, que es similar al volumen local de Docker para acceder a algunos recursos locales (como Docker local). gcePersistentDiskGCEdisk: solo disponible en la plataforma Google Cloud Engine. awsElasticBlockStore es similar a GCEdisk. El nodo debe ser una instancia del sistema de archivos de red compatible con AWSEC2 nfs. rbd-RadosBlockDevice-Ceph | secret se usa para transferir información confidencial a Pod a través de la API de Kubernetes, usando tmpfs (sistema de archivos respaldado por aRAM); solicite recursos del PV abstracto sin preocuparse por el proveedor de almacenamiento iscsi | apropiado según sus propias necesidades Tipos de almacenamiento, de todos modos, hay suficientes compatibles, siempre use uno adecuado :) 7) Algunos principios fundamentales de seguridad: Los módulos de infraestructura deben intercambiar datos y modificar el estado del sistema a través del servidor API, y solo el servidor API puede acceder almacenamiento back-end (etc.). Divida a los usuarios en diferentes roles: Desarrolladores/Administradores de Proyectos/Administradores. Permita que los desarrolladores definan objetos secretos y los asocien con contenedores relacionados cuando se inicie el pod. Tomando Secret como ejemplo, si Kubelet quiere extraer una imagen privada, Kubernetes admite los siguientes métodos: Genere un archivo .dockercfg a través de dockerlogin para autorización global. Autorice creando el objeto secreto del usuario en cada espacio de nombres y especificando el atributo imagePullSecrets al crear el Pod (también se puede configurar de manera uniforme en serviceAcouunt). Autenticación APIserver admite tres métodos de autenticación: certificado, token e información básica.

Autorización (Autorización) A través del puerto seguro de apiserver, la autorización se aplicará a todos los es. La función principal del cadvisor externo es capturar las métricas del contenedor del host del nodo. En versiones más recientes, la función cadvior está integrada en el componente kubelet y kubelet proporciona servicios de monitoreo externos mientras interactúa con Docker. El monitoreo de todo el clúster de Kubernetes se construye principalmente mediante kubelet, heapster y el backend de almacenamiento (como influxdb). Heapster puede obtener métricas y datos de eventos de todo el clúster. Se puede ejecutar como un módulo en la plataforma k8s o se puede ejecutar de forma independiente. Nota: Heapster aún no ha llegado a la versión 1.0, que es más conveniente para el monitoreo de clústeres a pequeña escala. Pero para grupos más grandes, el método de caché actual de Heapster consumirá mucha memoria. Debido a que la información del contenedor de todo el clúster debe obtenerse con regularidad, el almacenamiento temporal de la información en la memoria se convierte en un problema. Además, Heapter necesita admitir API para obtener métricas temporales. Si Heapster se ejecuta en modo pod, puede ocurrir fácilmente OOM. . Por lo tanto, actualmente se recomienda desactivar el caché y crear de forma independiente la plataforma k8s en modo independiente.