Kubernetes: uma solução de projeto pessoal incrivelmente acessível

Olá colegas!

Em janeiro, finalmente temos o tão esperado livro sobre Kubernetes. Discurso sobre a “Mastering Kubernetes 2nd edition” de Gigi Saifan:


Não ousamos publicar um livro no Kubernetes há cerca de um ano, já que naquela época a tecnologia definitivamente parecia um dreadnought para as super corporações. No entanto, a situação está mudando, em apoio ao qual sugerimos a leitura de um grande artigo de Caleb Doxsey, que, aliás, escreveu um livro sobre a linguagem Go. Os argumentos do Sr. Doxy são muito interessantes e esperamos que, depois de lê-los, você realmente queira experimentar o Kubernetes na prática.

Passei alguns meses no início deste ano em um estudo aprofundado do Kubernetes: eu precisava dele para um projeto de trabalho. O Kubernetes é uma tecnologia abrangente para gerenciamento de infraestrutura, que "inclui tudo, até baterias". O Kubernetes resolve vários problemas que você está fadado a encontrar ao desenvolver para grandes empresas. No entanto, a crença de que o Kubernetes é uma tecnologia excessivamente sofisticada e relevante apenas para gerenciar um grande cluster de máquinas é replicada. Alegadamente, a carga operacional ao trabalhar com o Kubernetes é tão grande que seu uso em pequenas infra-estruturas, onde a máquina não sai por dezenas, é um canhão disparando contra pardais.
Eu me permito discordar disso. O Kubernetes também é bom para pequenos projetos, e hoje você já pode comprar seu próprio cluster Kubernetes por menos de US $ 5 por mês.

Uma palavra em defesa de Kubernetes

Abaixo, mostrarei como configurar seu próprio cluster Kubernetes, mas primeiro tente explicar por que o Kubernetes deve ser usado em pequenos projetos:

Kubernetes é completo

Sim, à primeira vista, o Kubernetes parece uma solução um pouco redundante. Parece ser mais fácil obter e obter uma máquina virtual e não configurar seu próprio aplicativo como serviço, por que não? Escolhendo esse caminho, você terá que decidir sobre algumas soluções, em particular:

1. Como implantar o aplicativo? Apenas rsync-lo para o servidor?
2. E as dependências? Se você trabalha com Python ou Ruby, precisará instalá-los no servidor. Você vai apenas executar os comandos manualmente?
3. Como você vai iniciar o aplicativo? Basta executar o binário em segundo plano e depois nohup? Provavelmente isso não é muito bom; portanto, se você organizar o aplicativo como um serviço, precisará aprender o systemd?
4. Como você lida com a operação de muitos aplicativos quando todos eles têm nomes de domínio ou caminhos http diferentes? (você provavelmente precisará configurar haproxy ou nginx para isso)
5. Suponha que você atualizou seu aplicativo. Como então você lançará as mudanças? Pare o serviço, implante o código, reinicie o serviço? Como evitar o tempo de inatividade?
6. E se você bloquear a implantação? Existem oportunidades para reverter? (Diretório Symlink ...? Esse script simples não parece mais particularmente simples)
7. Seu aplicativo usa outros serviços, por exemplo, redis? Como configurar todos esses serviços?

Kubernetes resolve todos esses problemas. Naturalmente, todos eles são resolvidos de outras maneiras, entre as quais existem melhores opções para o Kubernetes; no entanto, quão melhor é não pensar nisso tudo e se concentrar no desenvolvimento de aplicativos.

Kubernetes é confiável

Um único servidor sempre trava. Sim, isso é raro, talvez uma vez por ano, mas após esse evento uma verdadeira dor de cabeça começa: como retornar tudo à condição de trabalho. Isso é especialmente verdadeiro se você tiver configurado manualmente toda a configuração. Lembra de todas as equipes que rodaram da última vez? Você se lembra do que funcionou no servidor? Lembro-me de uma citação de bashorg:

erno: Hmm. Perdi o computador ... sério, perdi. Ele responde, funciona bem, eu simplesmente não sei para onde ele foi no apartamento.
bash.org/?5273

Exatamente a mesma coisa aconteceu comigo recentemente em meu próprio blog. Eu só precisava atualizar o link, mas esqueci completamente como implantar o blog. De repente, uma correção de dez minutos se transformou em um trabalho durante um fim de semana inteiro.

O Kubernetes usa um formato descritivo , para que você sempre saiba quais coisas, quando e onde deveria correr; Além disso, todos os componentes do seu sistema implantado são muito mais claramente visíveis. Além disso, no plano de controle, a falha do nó é tratada com cuidado e as lareiras são redistribuídas automaticamente. Ao trabalhar com um serviço que não preserva o estado, por exemplo, com um aplicativo Web, você provavelmente pode esquecer completamente as falhas.

Aprender Kubernetes não é mais difícil do que alternativas

O Kubernetes não segue o modelo Unix. Não se encaixa no ecossistema de ferramentas. Ele não é uma daquelas decisões que "fazem apenas uma coisa e fazem bem". O Kubernetes é uma solução abrangente para muitos problemas, pois pode substituir uma variedade de truques e ferramentas às quais os desenvolvedores já se acostumaram.

O Kubernetes tem sua própria terminologia, suas próprias ferramentas, seu próprio paradigma de manipulação de servidor, que difere significativamente da abordagem tradicional do unix. Quando você navega nesses sistemas, muitos dos recursos do Kubernetes podem parecer aleatórios e complicados demais, talvez até cruéis. Suponho que existem boas razões para essa complexidade ter surgido, mas aqui não afirmo que o Kubernetes seja simples e elementar de entender; Estou dizendo que o conhecimento do Kubernetes é suficiente para criar e dar suporte a qualquer infraestrutura.

Isso não quer dizer que qualquer administrador de sistema tenha um histórico suficiente no unix. Por exemplo, depois de me formar na faculdade, trabalhei por 5 anos no ecossistema do Windows. Posso dizer que meu primeiro trabalho em uma startup em que eu precisava lidar com o Linux exigiu uma transformação difícil. Eu não conhecia os comandos de memória; não estou acostumado a usar a linha de comando em quase todas as ocasiões. Demorei um pouco para aprender a trabalhar com a nova plataforma (embora, naquela época, eu já tivesse alguma experiência em programação), mas lembro claramente o quanto sofri.

Com o Kubernetes, você pode começar todo o trabalho do zero. No Kubernetes, você pode provisionar serviços facilmente, mesmo sem uma conexão SSH com o servidor. Você não precisa aprender o systemd; não é necessário entender os níveis de execução ou saber qual comando foi usado: groupadd ou addgroup ; Você não precisa aprender a lidar com ps ou, Deus não permita, vim. Todo esse material é útil e importante, nada disso desaparece em lugar algum. Eu tenho um grande respeito pelos administradores de sistemas que são capazes de trabalhar em qualquer ambiente unix. Mas como seria legal se os desenvolvedores pudessem adquirir produtivamente todos esses recursos sem se aprofundar nessas sutilezas de administração?

É realmente isso:

 [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 

Muito mais difícil que isso?

 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 

E este ainda é um caso relativamente bom. Se você gerenciar a infraestrutura 100% remotamente, não poderá fornecer suporte manual ao servidor. Para fazer isso, você precisará de algum tipo de ferramenta: ansible, sal, chef, fantoche, etc. Naturalmente, para dominar o Kubernetes e trabalhar efetivamente com ele, você precisa aprender muito, mas isso não é mais difícil do que lidar com alternativas.

Código aberto Kubernetes

Na era da enorme popularidade das tecnologias sem servidor, a Kubernetes é notável por sua independência em relação a fornecedores específicos. Existem pelo menos três fornecedores populares e fáceis de gerenciar do Kubernetes (Google, Amazon, Microsoft) que não desaparecerão no futuro próximo. Também existem muitas empresas que gerenciam com êxito seus próprios clusters Kubernetes e todos os dias o número dessas empresas se multiplica. Hoje, trabalhar com o Kubernetes desde o primeiro dia é uma solução óbvia para a maioria das startups.
O Kubernetes, sendo um projeto de código aberto, é bem documentado, estável e popular, e qualquer problema pode ser tratado o máximo possível no fluxo de pilha. É claro que o Kubernetes tem seus próprios bugs e desafios técnicos, mas garanto: existem caras no mundo que aprimoram o Kubernetes com uma habilidade incrível. O trabalho deles é o seu dividendo; nos próximos anos, essa tecnologia só será aprimorada.

Escalas de Kubernetes

Um dos desafios associados ao suporte à infraestrutura é o seguinte: as técnicas que são úteis ao implantar pequenos sistemas raramente são bem-sucedidas na reprodução em sistemas maiores. Definitivamente, é conveniente ligar um arquivo binário ao servidor, matar o processo e reiniciá-lo se você tiver apenas um servidor. Porém, quando você precisa oferecer suporte a vários servidores e monitorá-los simultaneamente, essa tarefa pode se tornar incrivelmente difícil. É por isso que você não pode prescindir de ferramentas como chef ou fantoche ao gerenciar essa infraestrutura.

No entanto, se você escolher a ferramenta errada, com o tempo ela poderá encurralá-lo. De repente, verifica-se que o principal chef-servidor não consegue lidar com a carga de 1000 servidores, a implantação azul esverdeado não se encaixa no seu modelo e leva horas para concluir as tarefas do capistrano. Quando a infraestrutura atingir um determinado tamanho, você será forçado a derrubar tudo o que já foi feito e começar de novo. Quão grande seria se você pudesse sair dessa roda eterna de esquilos com infraestrutura e mudar para a tecnologia que será dimensionada de acordo com suas necessidades?

O Kubernetes é muito parecido com um banco de dados SQL. O SQL é o produto de muitos anos de lições difíceis sobre armazenamento de dados e consultas eficientes. Provavelmente, você nunca precisará de um décimo desses recursos fornecidos em um banco de dados SQL válido. Você pode até criar um sistema mais eficiente, contando com seu próprio banco de dados. Mas na grande maioria das situações, o banco de dados SQL não apenas satisfaz todas as suas necessidades, mas também aumenta drasticamente sua capacidade de emitir rapidamente soluções prontas. Os esquemas e a indexação SQL são muito mais fáceis de usar do que as estruturas de dados baseadas em arquivos nativos, já que as estruturas de dados nativas quase certamente se tornarão obsoletas à medida que o produto cresce e se desenvolve ao longo do tempo. Mas o banco de dados SQL provavelmente sobreviverá a qualquer refatoração inevitável.

Kubernetes também sobreviverá. Talvez seu projeto paralelo nunca chegue a uma escala em que seus problemas só possam ser resolvidos com o Kubernetes, mas o Kubernetes possui absolutamente todas as ferramentas para quaisquer problemas, e as habilidades que você obterá ao lidar com este kit de ferramentas podem se tornar inestimável em projetos futuros.

Crie seu próprio cluster Kubernetes

Portanto, acredito que é aconselhável usar o Kubernetes em pequenos projetos, mas somente se a configuração de um cluster for simples e barata. Acontece que ambos são viáveis. Existem provedores gerenciados pelo Kubernetes que lidam com toda a bagunça sozinhos, dando suporte ao plano de controle do host Kubernetes. E as recentes guerras de dumping no ambiente de infraestrutura em nuvem levaram a uma redução impressionante no custo de tais serviços.
Analisaremos o caso a seguir usando o mecanismo Kubernetes do Google (GKE) como exemplo; no entanto, você também pode consultar ofertas da Amazon (EKS) ou Microsoft (AKS) se o Google não lhe agradar. Para criar seu próprio cluster Kubernetes, precisamos:

• Nome de domínio (~ 10 $ / ano, dependendo do domínio)
• Hospedagem DNS Cloudflare (grátis)
• Cluster de três nós do GKE Kubernetes (~ US $ 5 / mês)
• Aplicativo da Web carregado como um contêiner de encaixe no Google Container Registry (GCR) (gratuito)
• Vários arquivos yaml para configuração do Kubernetes

Para economias adicionais, tentaremos ficar sem um controlador de entrada do Google. Em vez disso, usaremos o Nginx em cada nó como um daemon e criaremos nosso próprio operador que sincronizará os endereços IP externos do nó de trabalho com o Cloudflare.

Configuração do Google

Primeiro, acesse console.cloud.google.com e crie um projeto, se você ainda não o fez. Você também precisará criar uma conta de cobrança. Em seguida, no menu hambúrguer, vá para a página Kubernetes e crie um novo cluster. Aqui está o que você precisa fazer a seguir:

• Selecione Zonal para o tipo de local.
• Indiquei minha localização como us-central1-a
• Escolha sua versão do kubernetes
• Crie um pool de 3 nós usando o tipo de instância mais barato (f1-micro).
• Para esse conjunto de nós, na tela "avançada", defina o tamanho do disco de inicialização para 10 GB, ative os nós extrudados (são mais baratos), ative a atualização automática e o tratamento automático.
• Sob o conjunto de nós, você encontrará várias opções adicionais. Queremos desativar o balanceamento de carga HTTP (o balanceamento de carga no GCP é caro) e também desativar toda a economia associada ao StackDriver (também pode ser caro e, na minha experiência, não muito confiável). Desligue também o painel indicador do kubernetes.

Depois de colocar todas essas opções, você pode prosseguir para a próxima etapa: criar um cluster. Veja como economizar nele:

• Plano de controle Kubernetes: grátis, porque o Google não cobra nós de host
• Nós de trabalho do Kubernetes: US $ 5,04 / mês, como regra, três micronós custam US $ 11,65 / mês e, depois de eliminados, reduziremos essa taxa para US $ 7,67 / mês e, sempre grátis - para US $ 5,04.
• Custos de armazenamento: grátis. Recebemos gratuitamente 30 GB de espaço em disco permanente; portanto, escolhemos o tamanho de 10 GB.
• Custos do balanceamento de carga: de graça, desativamos o balanceamento de carga HTTP, pois apenas isso levaria US $ 18 / mês. Em vez disso, execute nossos próprios proxies HTTP em cada nó e direcione o DNS para o IP público.
• Despesas de rede: grátis, a função de saída permanece gratuita até você selecionar 1 GB por mês. (Em seguida, cada próximo gigabyte custa 8 centavos)

Por isso, montamos um cluster Kubernetes de 3 nós, que nos custou o mesmo preço que a única máquina Digital Ocean.

Além de configurar o GKE, você também precisa configurar algumas regras de firewall para poder acessar as portas HTTP de nossos hosts do mundo exterior. Localize a entrada Rede VPC no menu hambúrguer, vá para Regras de firewall e adicione as regras para as portas TCP 80 e 443, com o intervalo de endereços IP 0.0.0.0/0.



Regras de firewall

Configuração local

Então, criamos e iniciamos o cluster, e agora vamos configurá-lo. Instale a ferramenta gcloud seguindo as instruções em cloud.google.com/sdk/docs . Após a instalação, você pode prosseguir para a configuração fazendo o seguinte:

 gcloud auth login 

Obviamente, você ainda precisa instalar a janela de encaixe e vinculá-la ao GCR, para poder enviar contêineres:

 gcloud auth configure-docker 

Você também pode instalar e configurar o kubectl seguindo as instruções descritas aqui.

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 

A propósito, é apenas um conto de fadas que todo esse kit de ferramentas funciona no Windows, OSX ou Linux. Como uma pessoa que às vezes fez essas coisas no Windows, admito que é uma surpresa agradável.

Compilação de aplicativos da Web

Um aplicativo da web pode ser escrito em qualquer linguagem de programação. O contêiner permite abstrair o particular. Nós devemos criar um aplicativo HTTP escutando na porta. Eu prefiro o Go para esses propósitos, mas, para variar, tentaremos o cristal. Crie o arquivo 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 

Também precisamos de um 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 criar e testar nosso aplicativo, execute:

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

E, em seguida, vá para o navegador em localhost: 8080. Após estabelecer esse mecanismo, podemos enviar nosso aplicativo ao GCR executando:

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

Configurar o Kubernetes

Minha configuração do Kubernetes está aqui .

Neste exemplo, teremos que criar vários arquivos yaml onde nossos vários serviços serão apresentados e, em seguida, execute o kubectl apply para configurá-los no cluster. A configuração do Kubernetes é descritiva e todos esses arquivos yaml informam ao Kubernetes qual o estado que queremos obter. Em um sentido amplo, é isso que vamos fazer:

• Crie Implantação e Serviço para nosso aplicativo Web crystal-www-example
• Criar conjunto de daemon (conjunto de serviços) e mapa de configuração (mapa de configuração) para nginx
• Lançamos nosso próprio aplicativo para sincronizar nós IP com o Cloudflare for DNS

Configuração de aplicativo da Web

Primeiro, vamos configurar nosso aplicativo da Web: (certifique-se de substituir PROJECT_ID pelo ID do seu projeto)

 # 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 

Isso cria uma implantação (configuração expandida), segundo a qual o Kubernetes deve criar um único contêiner (nosso contêiner de docker funcionará lá) e um serviço que usaremos para encontrar serviços em nosso cluster. Para aplicar esta configuração, execute (no diretório kubernetes-config ):

 kubectl apply -f 

Você pode testá-lo assim:

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

Também podemos criar uma API proxy para acesso:

 kubectl proxy 

E então vá: localhost : 8001 / api / v1 / namespaces / padrão / services / crystal-www-example / proxy /

Configuração NGINX

Normalmente, ao trabalhar com serviços HTTP, o Kubernetes usa um controlador de entrada. Infelizmente, o balanceador de carga HTTP do Google é muito caro, por isso não o usamos, mas usamos nosso próprio proxy HTTP e o configuramos manualmente (parece assustador, mas na realidade é muito simples).

Para fazer isso, use o Conjunto de Daemon e o Mapa de Configuração. Daemon Set é um aplicativo que é executado em todos os nós. O mapa de configuração é, em princípio, um pequeno arquivo que podemos montar em um contêiner; esse arquivo armazenará a configuração nginx.
O arquivo yaml se parece com isso:

 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; } } } 

É assim que montamos o arquivo nginx.conf da placa de configuração no contêiner nginx. Também definimos valores para mais dois campos: hostNetwork: true , para que você possa vincular a porta do host e alcançar o nginx de fora e dnsPolicy: ClusterFirstWithHostNet para poder acessar serviços dentro do cluster. Se isso não for feito, obteremos uma configuração completamente padrão.

Aplique essas expressões e você poderá acessar o nginx através do ip público de seus nós.

Veja como você pode verificar isso:

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

Portanto, agora nosso aplicativo da Web está acessível na Internet. Resta criar um nome bonito para o aplicativo.

Conexão DNS

É necessário definir 3 registros DNS A para os nós do cluster:



Entradas na interface do usuário Cloudflare

Em seguida, adicione um registro CNAME para apontar para esses registros A. (por exemplo, www.example.com CNAME para kubernetes.example.com). Isso pode ser feito manualmente, mas melhor - automaticamente, para que, se precisarmos escalar ou substituir nós nos registros DNS, essas informações também sejam atualizadas automaticamente.

Acho que este exemplo também ilustra bem como você pode delegar parte do seu trabalho ao Kubernetes, e não tentar superá-lo. O Kubernetes entende scripts e possui uma API poderosa, e você pode preencher os espaços existentes com seus próprios componentes, que não são tão difíceis de escrever. Para fazer isso, criei um pequeno aplicativo no Go, disponível neste endereço: kubernetes-cloudflare-sync .

Para começar, criei um 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) 

Ele chamará minha função de ressincronização sempre que um nó for alterado. Então, sincronizo a API usando a biblioteca da API Cloudflare , algo como isto:

 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, }) } 

Em seguida, como em nosso aplicativo Web, lançamos esse aplicativo no Kubernetes como uma implantação:

 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 

Precisamos criar um segredo do cloudflare api especificando a chave da cloudflare api do cloudflare api e o endereço para correspondência:

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

Também precisaremos criar uma conta de serviço (fornecendo acesso à Deployment à API Kubernetes para recuperar nós). Primeira execução (especialmente para GKE):

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

E depois 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 

Trabalhar com o RBAC é um pouco entediante, mas espero que tudo esteja claro aqui. Quando a configuração estiver pronta e nosso aplicativo funcionar com o Cloudflare, esse aplicativo poderá ser atualizado com qualquer alteração em qualquer um dos nós.

Conclusão

O Kubernetes está destinado a se tornar a principal tecnologia para gerenciar grandes sistemas. , Kubernetes , Kubernetes , Kubernetes , Kubernetes .

, Kubernetes : , . – !