Kubernetes: una solución de proyecto personal increíblemente asequible

Hola colegas

En enero, finalmente tenemos el libro tan esperado sobre Kubernetes. Discurso sobre la "Segunda edición de Mastering Kubernetes" de Gigi Saifan:


No nos atrevimos a publicar un libro sobre Kubernetes hace aproximadamente un año, ya que en ese momento la tecnología definitivamente parecía un dreadnought para las súper corporaciones. Sin embargo, la situación está cambiando, en apoyo de lo cual sugerimos leer un gran artículo de Caleb Doxsey, quien, por cierto, escribió un libro sobre el lenguaje Go. Los argumentos del Sr. Doxy son muy interesantes, y esperamos que después de leerlos realmente quiera probar Kubernetes en la práctica.

Pasé unos meses a principios de este año en un estudio en profundidad de Kubernetes: lo necesitaba para un proyecto de trabajo. Kubernetes es una tecnología integral para la gestión de la infraestructura, "incluye todo, incluso las baterías". Kubernetes resuelve una serie de problemas con los que está condenado a enfrentarse al desarrollar para grandes empresas. Sin embargo, se replica la creencia de que Kubernetes es una tecnología demasiado sofisticada que solo es relevante para administrar un gran grupo de máquinas. Supuestamente, la carga operativa cuando se trabaja con Kubernetes es tan grande que su uso para pequeñas infraestructuras, donde la máquina no funciona durante docenas, es un cañón disparando a los gorriones.
Me permito estar en desacuerdo con esto. Kubernetes también es bueno para proyectos pequeños, y hoy ya puede pagar su propio clúster de Kubernetes por menos de $ 5 por mes.

Una palabra en defensa de Kubernetes

A continuación, le mostraré cómo configurar su propio clúster de Kubernetes, pero primero trate de explicar por qué Kubernetes debería usarse en pequeños proyectos:

Kubernetes es minucioso

Sí, a primera vista, Kubernetes parece una solución algo redundante. Parece ser más fácil obtener y obtener una máquina virtual y no configurar su propia aplicación como servicio, ¿por qué no? Al elegir este camino, tendrá que decidir algunas soluciones, en particular:

1. ¿Cómo implementar la aplicación? ¿Solo rsync al servidor?
2. ¿Qué pasa con las dependencias? Si trabaja con Python o Ruby, deberá instalarlos en el servidor. ¿Vas a ejecutar los comandos manualmente?
3. ¿Cómo vas a lanzar la aplicación? Simplemente ejecute el binario en segundo plano y luego ¿no? Esto probablemente no sea demasiado bueno, así que si organiza la aplicación como un servicio, ¿tiene que aprender systemd?
4. ¿Cómo manejará el funcionamiento de muchas aplicaciones cuando todas tienen diferentes nombres de dominio o rutas http? (probablemente necesite configurar haproxy o nginx para esto)
5. Supongamos que ha actualizado su aplicación. ¿Cómo, entonces, implementarán los cambios? ¿Detener el servicio, implementar el código, reiniciar el servicio? ¿Cómo evitar el tiempo de inactividad?
6. ¿Qué pasa si bloquea la implementación? ¿Hay oportunidades para retroceder? (Directorio de enlaces simbólicos ...? Este script simple ya no parece particularmente simple)
7. ¿Su aplicación utiliza otros servicios, por ejemplo, redis? ¿Cómo configurar todos estos servicios?

Kubernetes resuelve todos estos problemas. Naturalmente, todos se resuelven de otras maneras, entre las cuales hay mejores opciones para Kubernetes; sin embargo, qué mejor es no pensar en todo esto y enfocarse en el desarrollo de aplicaciones.

Kubernetes es confiable

Un solo servidor siempre se bloqueará. Sí, esto es raro, tal vez una vez al año, pero después de tal evento comienza un verdadero dolor de cabeza: cómo devolver todo a su condición de trabajo. Esto es especialmente cierto si usted mismo configuró manualmente toda la configuración. ¿Recuerdas todos los equipos que corrieron la última vez? ¿Recuerdas lo que funcionó en el servidor? Recuerdo una cita de bashorg:

erno: Hmm. Perdí la computadora ... en serio, perdida. Él responde, funciona bien, simplemente no sabré a dónde fue en el apartamento.
bash.org/?5273

Exactamente lo mismo me ha sucedido recientemente en mi propio blog. Solo necesitaba actualizar el enlace, pero olvidé por completo cómo implementar el blog. De repente, una reparación de diez minutos se convirtió en una tarea durante todo un fin de semana.

Kubernetes utiliza un formato descriptivo , por lo que siempre sabe qué cosas, cuándo y dónde se suponía que debía ejecutarse; Además, todos los componentes de su sistema implementado son mucho más claramente visibles. Además, en el plano de control, la falla del nodo se maneja con cuidado, y los hogares se redistribuyen automáticamente. Al trabajar con un servicio que no conserva el estado, por ejemplo, con una aplicación web, probablemente pueda olvidarse por completo de las fallas.

Aprender Kubernetes no es más difícil que las alternativas

Kubernetes no sigue el modelo de Unix. No encaja en el ecosistema de herramientas. Él no es una de esas decisiones que "hacen una sola cosa y lo hacen bien". Kubernetes es una solución integral para muchos problemas, puede reemplazar una variedad de trucos y herramientas a los que los desarrolladores ya se han acostumbrado.

Kubernetes tiene su propia terminología, sus propias herramientas, su propio paradigma de manejo del servidor, que difiere significativamente del enfoque tradicional de Unix. Cuando navega por estos sistemas, muchas de las características de Kubernetes pueden parecer aleatorias y complicadas, incluso crueles. Supongo que hay buenas razones por las que ha surgido esta complejidad, pero aquí no estoy diciendo que Kubernetes sea simple y elemental de entender; Estoy diciendo que el conocimiento de Kubernetes es suficiente para crear y soportar cualquier infraestructura.

Esto no quiere decir que ningún administrador del sistema tenga experiencia suficiente en Unix. Por ejemplo, después de graduarme de la universidad, trabajé durante 5 años en el ecosistema de Windows. Puedo decir que mi primer trabajo en una startup donde necesitaba lidiar con Linux requería una transformación difícil. No conocía los comandos para la memoria; no estoy acostumbrado a usar la línea de comandos para casi todas las ocasiones. Me llevó un tiempo aprender a trabajar con la nueva plataforma (aunque para entonces ya tenía algo de experiencia en programación), pero recuerdo claramente cuánto sufrí.

Con Kubernetes, puede comenzar todo el trabajo desde cero. En Kubernetes, puede aprovisionar servicios fácilmente incluso sin una conexión SSH al servidor. No tienes que aprender systemd; no es necesario comprender los niveles de ejecución o saber qué comando se usó: groupadd o addgroup ; No tienes que aprender a manejar ps o, Dios no lo quiera, vim. Todo este material es útil e importante, nada de él desaparece en ningún lado. Tengo un gran respeto por los administradores de sistemas que pueden abrirse camino a través de cualquier entorno unix. Pero, ¿qué tan genial sería si los desarrolladores pudieran adquirir productivamente todos esos recursos sin profundizar en tales sutilezas de administración?

¿Es realmente esto?

 [Unit] Description=The NGINX HTTP and reverse proxy server After=syslog.target network.target remote-fs.target nss-lookup.target [Service] Type=forking PIDFile=/run/nginx.pid ExecStartPre=/usr/sbin/nginx -t ExecStart=/usr/sbin/nginx ExecReload=/usr/sbin/nginx -s reload ExecStop=/bin/kill -s QUIT $MAINPID PrivateTmp=true [Install] WantedBy=multi-user.target 

¿Mucho más difícil que esto?

 apiVersion: apps/v1 kind: Deployment metadata: name: my-nginx spec: selector: matchLabels: run: my-nginx replicas: 1 template: metadata: labels: run: my-nginx spec: containers: - name: my-nginx image: nginx ports: - containerPort: 80 

Y este sigue siendo un caso relativamente bueno. Si administra la infraestructura de forma 100% remota, no podrá proporcionar soporte manual del servidor. Para hacer esto, necesitará algún tipo de herramienta: ansible, sal, chef, marioneta, etc. Naturalmente, para dominar Kubernetes y trabajar eficazmente con él, debes aprender mucho, pero esto no es más difícil que lidiar con alternativas.

Código abierto de Kubernetes

En la era de la gran popularidad de las tecnologías sin servidor, Kubernetes destaca por su independencia de proveedores específicos. Hay al menos 3 proveedores populares y fáciles de administrar de Kubernetes (Google, Amazon, Microsoft) que no desaparecerán en el futuro previsible. También hay muchas compañías que gestionan con éxito sus propios grupos de Kubernetes, y cada día se multiplica el número de tales compañías. Hoy, trabajar con Kubernetes desde el primer día es una solución obvia para la mayoría de las nuevas empresas.
Kubernetes, siendo un proyecto de código abierto, está bien documentado, es estable y popular, y cualquier problema puede ser tratado con el mayor detalle posible en stackoverflow. Por supuesto, Kubernetes tiene sus propios errores y desafíos técnicos, pero te lo aseguro: hay hombres en el mundo que perfeccionan a Kubernetes con una habilidad increíble. Su trabajo son tus dividendos; En los próximos años, esta tecnología solo se mejorará.

Escamas de Kubernetes

Uno de los desafíos asociados con el soporte de la infraestructura es este: las técnicas que son útiles al implementar sistemas pequeños rara vez tienen éxito en la reproducción en sistemas más grandes. Definitivamente es conveniente vincular SCP un archivo binario al servidor, eliminar el proceso y reiniciarlo si solo tiene un servidor. Pero, cuando necesita soportar varios servidores y monitorearlos simultáneamente, tal tarea puede resultar asombrosamente difícil. Es por eso que no puede prescindir de herramientas como chef o títeres al administrar dicha infraestructura.

Sin embargo, si elige la herramienta incorrecta, con el tiempo puede llevarlo a una esquina. De repente, resulta que el chef-servidor líder no puede hacer frente a la carga de 1000 servidores, el despliegue azul-verde no se ajusta a su modelo y lleva horas completar las tareas de capistrano. Cuando la infraestructura alcanza un cierto tamaño, se verá obligado a derribar todo lo que ya se ha hecho y comenzar de nuevo. ¿Qué tan bueno sería si pudieras salir de esta rueda de ardilla eterna con infraestructura y cambiar a una tecnología que se adapte a tus necesidades?

Kubernetes se parece mucho a una base de datos SQL. SQL es el producto de muchos años de lecciones difíciles sobre almacenamiento de datos y consultas eficientes. Probablemente, nunca necesitará ni una décima parte de las características que se proporcionan en una base de datos SQL válida. Incluso podría diseñar un sistema más eficiente, basándose en su propia base de datos. Pero en la gran mayoría de las situaciones, la base de datos SQL no solo satisfará todas sus necesidades, sino que ampliará drásticamente su capacidad para emitir rápidamente soluciones listas para usar. Los esquemas y la indexación de SQL son mucho más fáciles de usar que las estructuras de datos nativas basadas en archivos, ya que las estructuras de datos nativas seguramente se volverán obsoletas a medida que su producto crezca y se desarrolle con el tiempo. Pero es probable que la base de datos SQL sobreviva a cualquier refactorización inevitable.

Kubernetes también sobrevivirá. Quizás su proyecto paralelo nunca crecerá a una escala tal que sus problemas solo puedan resolverse usando las herramientas de Kubernetes, pero Kubernetes tiene absolutamente todas las herramientas para cualquier problema, y ​​las habilidades que obtendrá al tratar con este kit de herramientas pueden resultar ser invaluable en futuros proyectos.

Construye tu propio clúster de Kubernetes

Por lo tanto, creo que es aconsejable usar Kubernetes en proyectos pequeños, pero solo si la configuración de un clúster resulta simple y económica. Resulta que ambos son alcanzables. Hay proveedores administrados de Kubernetes que se encargan de todo el desastre por sí mismos, lo que admite el plano de control del host Kubernetes. Y las recientes guerras de dumping en el entorno de infraestructura en la nube han llevado a una asombrosa reducción en el costo de dichos servicios.
Analizaremos el siguiente caso utilizando el motor Kubernetes de Google (GKE) como ejemplo, sin embargo, también puede ver las ofertas de Amazon (EKS) o Microsoft (AKS) si Google no le conviene. Para construir su propio clúster de Kubernetes, necesitamos:

• Nombre de dominio (~ 10 $ / año, dependiendo del dominio)
• Cloudflare DNS hosting (gratis)
• Grupo de tres nodos Guber Kubernetes (~ $ 5 / mes)
• Aplicación web cargada como contenedor acoplable al Registro de contenedores de Google (GCR) (gratis)
• Varios archivos yaml para la configuración de Kubernetes

Para ahorros adicionales, intentaremos prescindir de un controlador de entrada de Google. En su lugar, utilizaremos Nginx en cada nodo como demonio y crearemos nuestro propio operador que sincronizará las direcciones IP externas del nodo de trabajo con Cloudflare.

Configuración de Google

Primero, vaya a console.cloud.google.com y cree un proyecto, si aún no lo ha hecho. También deberá crear una cuenta de facturación. Luego, a través del menú de hamburguesas, vaya a la página de Kubernetes y cree un nuevo clúster. Esto es lo que debe hacer a continuación:

• Seleccione Zonal para el tipo de ubicación.
• Indiqué mi ubicación como us-central1-a
• Elige tu versión de kubernetes
• Cree un grupo de 3 nodos utilizando el tipo de instancia más barato (f1-micro).
• Para este grupo de nodos, en la pantalla "avanzada", configure el tamaño del disco de arranque en 10 GB, habilite los nodos extruidos (son más baratos), habilite la actualización automática y el tratamiento automático.
• Debajo del grupo de nodos, encontrará una serie de opciones adicionales. Queremos deshabilitar el equilibrio de carga HTTP (el equilibrio de carga en GCP es costoso) y también deshabilitar toda la economía asociada con StackDriver (también puede ser costoso y, en mi experiencia, no muy confiable). También apague el panel indicador de kubernetes.

Después de poner todas estas opciones, puede continuar con el siguiente paso: crear un clúster. Aquí le mostramos cómo ahorrar:

• Plano de control de Kubernetes: gratis, porque Google no cobra nodos de host
• Nodos de trabajo de Kubernetes: $ 5.04 / mes, por regla general, 3 micro-nodos le costarán $ 11.65 / mes, y habiéndolos desplazado, reduciremos esta tasa a $ 7.67 / mes, y en Siempre gratis - a $ 5.04.
• Costos de almacenamiento: gratis. Obtenemos 30GB gratis de espacio en disco permanente, por lo que elegimos el tamaño de 10GB.
• Costos del equilibrio de carga: de forma gratuita, desactivamos el equilibrio de carga HTTP, ya que solo nos llevaría $ 18 / mes. En su lugar, ejecute nuestros propios proxies HTTP en cada nodo y dirija el DNS a una IP pública.
• Gastos de red: gratis, la función de salida permanece libre hasta que seleccione 1GB por mes. (A continuación, cada próximo gigabyte cuesta 8 centavos)

Entonces, configuramos un grupo de Kubernetes de 3 nodos, nos costó el mismo precio que la única máquina Digital Ocean.

Además de configurar GKE, también debe configurar un par de reglas de firewall para poder llegar a los puertos HTTP de nuestros hosts desde el mundo exterior. Busque la entrada de red VPC en el menú de hamburguesas, luego vaya a las Reglas de firewall y agregue las reglas para los puertos TCP 80 y 443, con el rango de direcciones IP 0.0.0.0/0.



Reglas de firewall

Entorno local

Entonces, levantamos y comenzamos el clúster, y ahora vamos a configurarlo. Instale la herramienta gcloud siguiendo las instrucciones en cloud.google.com/sdk/docs . Después de instalarlo, puede continuar con la configuración haciendo esto:

 gcloud auth login 

Por supuesto, aún debe instalar la ventana acoplable y luego vincularla al GCR para poder enviar contenedores:

 gcloud auth configure-docker 

También puede instalar y configurar kubectl siguiendo las instrucciones descritas aquí.

Simplificado:

 gcloud components install kubectl gcloud config set project PROJECT_ID gcloud config set compute/zone COMPUTE_ZONE gcloud container clusters get-credentials CLUSTER_NAME 

Por cierto, es solo un cuento de hadas que todo este kit de herramientas funciona en Windows, OSX o Linux. Como una persona que a veces ha hecho tales cosas bajo Windows, admito que es una sorpresa agradable.

Compilación de aplicaciones web

Una aplicación web se puede escribir en cualquier lenguaje de programación. El contenedor le permite abstraer lo particular. Debemos crear una aplicación HTTP que escuche en el puerto. Prefiero ir para tales propósitos, pero para variar intentaremos con el cristal. Cree el archivo main.cr :

 # crystal-www-example/main.cr require "http/server" Signal::INT.trap do exit end server = HTTP::Server.new do |context| context.response.content_type = "text/plain" context.response.print "Hello world from crystal-www-example! The time is #{Time.now}" end server.bind_tcp("0.0.0.0", 8080) puts "Listening on http://0.0.0.0:8080" server.listen 

También necesitamos un Dockerfile:

 # crystal-www-example/Dockerfile FROM crystallang/crystal:0.26.1 as builder COPY main.cr main.cr RUN crystal build -o /bin/crystal-www-example main.cr --release ENTRYPOINT [ "/bin/crystal-www-example" ] 

Para compilar y probar nuestra aplicación, ejecute:

 docker build -t gcr.io/PROJECT_ID/crystal-www-example:latest . docker run -p 8080:8080 gcr.io/PROJECT_ID/crystal-www-example:latest 

Y luego vaya al navegador en localhost: 8080. Una vez establecido este mecanismo, podemos enviar nuestra aplicación a GCR ejecutando:

 docker push gcr.io/PROJECT_ID/crystal-www-example:latest 

Configurar Kubernetes

Mi configuración de Kubernetes está aquí .

Para este ejemplo, tendremos que crear varios archivos yaml, donde se presentarán nuestros diversos servicios, y luego ejecutar kubectl apply para configurarlos en el clúster. La configuración de Kubernetes es descriptiva, y todos estos archivos yaml le dicen a Kubernetes qué estado queremos obtener. En un sentido amplio, esto es lo que vamos a hacer:

• Crear implementación y servicio para nuestra aplicación web crystal-www-example
• Crear Daemon Set (conjunto de servicios) y Config Map (mapa de configuración) para nginx
• Lanzamos nuestra propia aplicación para sincronizar nodos IP con Cloudflare para DNS

Configuración de la aplicación web

Primero, configuremos nuestra aplicación web: (asegúrese de reemplazar PROJECT_ID con la identificación de su proyecto)

 # kubernetes-config/crystal-www-example.yaml apiVersion: apps/v1 kind: Deployment metadata: name: crystal-www-example labels: app: crystal-www-example spec: replicas: 1 selector: matchLabels: app: crystal-www-example template: metadata: labels: app: crystal-www-example spec: containers: - name: crystal-www-example image: gcr.io/PROJECT_ID/crystal-www-example:latest ports: - containerPort: 8080 --- kind: Service apiVersion: v1 metadata: name: crystal-www-example spec: selector: app: crystal-www-example ports: - protocol: TCP port: 8080 targetPort: 8080 

Esto crea una implementación (configuración expandida), según la cual Kubernetes debe crear un único contenedor (nuestro contenedor acoplable funcionará allí) y un servicio que usaremos para encontrar servicios en nuestro clúster. Para aplicar esta configuración, ejecute (desde el directorio kubernetes-config ):

 kubectl apply -f 

Puedes probarlo así:

 kubectl get pod #     : # crystal-www-example-698bbb44c5-l9hj9 1/1 Running 0 5m 

También podemos crear una API proxy para el acceso:

 kubectl proxy 

Y luego vaya: localhost : 8001 / api / v1 / namespaces / default / services / crystal-www-example / proxy /

Configuración NGINX

Normalmente, cuando se trabaja con servicios HTTP, Kubernetes usa un controlador de entrada. Desafortunadamente, el equilibrador de carga HTTP de Google es demasiado costoso, por lo que no lo usaremos, pero usaremos nuestro propio proxy HTTP y lo configuraremos manualmente (suena aterrador, pero en realidad es muy simple).

Para hacer esto, use Daemon Set y Config Map. Daemon Set es una aplicación que se ejecuta en cada nodo. Config Map es, en principio, un pequeño archivo que podemos montar en un contenedor; Este archivo almacenará la configuración nginx.
El archivo yaml se ve así:

 apiVersion: apps/v1 kind: DaemonSet metadata: name: nginx labels: app: nginx spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: hostNetwork: true dnsPolicy: ClusterFirstWithHostNet containers: - image: nginx:1.15.3-alpine name: nginx ports: - name: http containerPort: 80 hostPort: 80 volumeMounts: - name: "config" mountPath: "/etc/nginx" volumes: - name: config configMap: name: nginx-conf --- apiVersion: v1 kind: ConfigMap metadata: name: nginx-conf data: nginx.conf: | worker_processes 1; error_log /dev/stdout info; events { worker_connections 10; } http { access_log /dev/stdout; server { listen 80; location / { proxy_pass http://crystal-www-example.default.svc.cluster.local:8080; } } } 

Así es como montamos el archivo nginx.conf de la tarjeta de configuración en el contenedor nginx. También establecemos valores para dos campos más: hostNetwork: true , para que pueda vincular el puerto del host y llegar a nginx desde el exterior y dnsPolicy: ClusterFirstWithHostNet para que pueda acceder a los servicios dentro del clúster. Si esto no se hace, obtendremos una configuración completamente estándar.

Aplica estas expresiones y puedes acceder a nginx a través de la ip pública de tus nodos.

Así es como puedes verificar esto:

 kubectl get node -o yaml # look for: # - address: ... # type: ExternalIP 

Así que ahora nuestra aplicación web es accesible desde Internet. Queda por encontrar un hermoso nombre para la aplicación.

Conexión DNS

Se requiere establecer 3 registros DNS A para los nodos de nuestro clúster:



Entradas en la IU Cloudflare

Luego agregue un registro CNAME para apuntar a estos registros A. (por ejemplo, www.example.com CNAME para kubernetes.example.com). Esto puede hacerse manualmente, pero mejor, automáticamente, de modo que si alguna vez necesitamos escalar o reemplazar nodos en registros DNS, esta información también se actualiza automáticamente.

Creo que este ejemplo también ilustra bien cómo puede delegar parte de su trabajo a Kubernetes, y no tratar de superarlo. Kubernetes entiende los scripts y tiene una API poderosa, y puede completar los espacios existentes con sus propios componentes, que no son tan difíciles de escribir. Para hacer esto, hice una pequeña aplicación en Go, disponible en esta dirección: kubernetes-cloudflare-sync .

Para comenzar, creé un informante:

 factory := informers.NewSharedInformerFactory(client, time.Minute) lister := factory.Core().V1().Nodes().Lister() informer := factory.Core().V1().Nodes().Informer() informer.AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc: func(obj interface{}) { resync() }, UpdateFunc: func(oldObj, newObj interface{}) { resync() }, DeleteFunc: func(obj interface{}) { resync() }, }) informer.Run(stop) 

Llamará a mi función de resincronización cada vez que cambie un nodo. Luego sincronizo la API usando la biblioteca API de Cloudflare , algo como esto:

 var ips []string for _, node := range nodes { for _, addr := range node.Status.Addresses { if addr.Type == core_v1.NodeExternalIP { ips = append(ips, addr.Address) } } } sort.Strings(ips) for _, ip := range ips { api.CreateDNSRecord(zoneID, cloudflare.DNSRecord{ Type: "A", Name: options.DNSName, Content: ip, TTL: 120, Proxied: false, }) } 

Luego, como con nuestra aplicación web, lanzamos esta aplicación en Kubernetes como implementación:

 apiVersion: apps/v1 kind: Deployment metadata: name: kubernetes-cloudflare-sync labels: app: kubernetes-cloudflare-sync spec: replicas: 1 selector: matchLabels: app: kubernetes-cloudflare-sync template: metadata: labels: app: kubernetes-cloudflare-sync spec: serviceAccountName: kubernetes-cloudflare-sync containers: - name: kubernetes-cloudflare-sync image: gcr.io/PROJECT_ID/kubernetes-cloudflare-sync args: - --dns-name=kubernetes.example.com env: - name: CF_API_KEY valueFrom: secretKeyRef: name: cloudflare key: api-key - name: CF_API_EMAIL valueFrom: secretKeyRef: name: cloudflare key: email 

Necesitaremos crear un secreto de Kubernetes especificando la clave de la cloudflare api y la dirección de correo:

 kubectl create secret generic cloudflare --from-literal=email='EMAIL' --from-literal=api-key='API_KEY' 

También necesitaremos crear una cuenta de servicio (dando acceso a nuestra implementación a la API de Kubernetes para recuperar nodos). Primera ejecución (especialmente para GKE):

 kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user YOUR_EMAIL_ADDRESS_HERE 

Y luego aplique:

 apiVersion: v1 kind: ServiceAccount metadata: name: kubernetes-cloudflare-sync --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: kubernetes-cloudflare-sync rules: - apiGroups: [""] resources: ["nodes"] verbs: ["list", "watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: kubernetes-cloudflare-sync-viewer roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: kubernetes-cloudflare-sync subjects: - kind: ServiceAccount name: kubernetes-cloudflare-sync namespace: default 

Trabajar con RBAC es un poco tedioso, pero espero que todo esté claro aquí. Cuando la configuración está lista y nuestra aplicación funciona con Cloudflare, esta aplicación se puede actualizar con cualquier cambio en cualquiera de los nodos.

Conclusión

Kubernetes está destinado a convertirse en la tecnología insignia para la gestión de grandes sistemas. , Kubernetes , Kubernetes , Kubernetes , Kubernetes .

, Kubernetes : , . – !