Estamos desenvolvendo um ambiente para trabalhar com microsserviços. Parte 1 instalando o Kubernetes HA no bare metal (Debian)

Olá queridos leitores da Habr!

Com esta publicação, desejo iniciar uma série de artigos sobre a implantação de um ambiente de orquestração completo com contêineres Kubernetes, que estará pronto para operação e lançamento de aplicativos.
Quero contar não apenas sobre como implantar um cluster Kubernetes, mas também sobre como configurar um cluster após a instalação, como adicionar ferramentas e complementos convenientes a ele para usar a arquitetura de microsserviço.

Esse ciclo consistirá em no mínimo quatro artigos:

1. No primeiro deles, mostrarei como instalar um cluster kubernetes à prova de falhas no ferro puro, como instalar um painel padrão e configurar o acesso a ele, como instalar um controlador de entrada.
2. No segundo artigo, mostrarei como implantar um cluster de failover Ceph e como começar a usar volumes RBD em nosso cluster Kubernetes. Também abordarei outros tipos de armazenamento (armazenamento) e considerarei o armazenamento local com mais detalhes. Além disso, mostrarei como organizar o armazenamento tolerante a falhas do S3 com base no cluster CEPH criado
3. No terceiro artigo, descreverei como implantar um cluster de failover MySql em nosso cluster Kubernetes, a saber, o Percona XtraDB Cluster no Kubernetes. E também descreverei todos os problemas que encontramos quando decidimos transferir o banco de dados para o kubernetes.
4. No quarto artigo, tentarei reunir tudo e explicar como implantar e executar um aplicativo que usará os volumes de banco de dados e ceph. Vou explicar como configurar o controlador de ingresso para acessar nosso aplicativo de fora e o serviço de pedido automático de certificados em Let's Encrypt. Outra é como manter automaticamente esses certificados atualizados. Também abordaremos o RBAC no contexto de acesso ao painel de controle. Vou falar em poucas palavras sobre o Helm e sua instalação.
   Se você estiver interessado nas informações dessas publicações, seja bem-vindo!

Entrada:

Para quem são esses artigos? Primeiro de tudo, para aqueles que estão apenas começando sua jornada no estudo de Kubernetes. Além disso, esse ciclo será útil para engenheiros que estão pensando em mudar de um monólito para microsserviços. Tudo o que foi descrito é a minha experiência, incluindo o obtido ao traduzir vários projetos de um monólito para Kubernetes. É possível que algumas partes das publicações sejam de interesse de engenheiros experientes.

O que não considerarei em detalhes nesta série de publicações:

• explique em detalhes o que são os primitivos do kubernetes, como: pod, implantação, serviço, entrada etc.
• Considerarei a CNI (Container Networking Interface) muito superficialmente, usamos o callico, portanto, outras soluções, apenas listarei.
• processo de criação da imagem do docker.
• Processos CI \ CD. (Talvez uma publicação separada, mas após todo o ciclo)
• leme; muito já foi escrito sobre ele, vou abordar apenas o processo de instalação no cluster e configuração do cliente.

O que eu quero considerar em detalhes:

• Processo passo a passo da implantação do cluster Kubernetes. Vou usar o kubeadm. Mas, ao mesmo tempo, examinarei passo a passo o processo de instalação de um cluster no bare metal, vários tipos de instalação do ETCD e a configuração de arquivos para o kube admina. Tentarei esclarecer todas as opções de balanceamento para o controlador Ingress e a diferença nos vários esquemas de acesso dos nós de trabalho à API do servidor.
  Eu sei que hoje para a implantação do kubernetes existem muitas ferramentas excelentes, como o kubespray ou o mesmo fazendeiro. Talvez seja mais conveniente para alguém usá-los. Mas acho que existem muitos engenheiros que querem considerar o assunto com mais detalhes.
• Terminologia do CEPH e instalação passo a passo do cluster CEPH, bem como instruções passo a passo sobre como conectar o armazenamento ceph ao cluster criado pelo Kubernetes.
• armazenamentos locais, conexão com o cluster kubernetes, bem como diferenças de conexões como caminho do host, etc.
• operadores kubernetes e a implantação do Percona XtraDB Cluster com a ajuda do operador, além de tentar falar sobre os prós e contras dessa solução após seis meses de experiência em produção. E também vou compartilhar alguns planos para finalizar o operador da percona.

Sumário:

1. Lista de hosts, recursos de host, versões de SO e software
2. Diagrama de HA do cluster Kubernetes
3. Antes de começar ou antes de começar
4. Preencha o arquivo create-config.sh
5. Atualização do kernel do SO
6. Preparando nós Instalando o Kubelet, Kubectl, Kubeadm e Docker
7. Instalando o ETCD (várias opções)
8. Iniciando o primeiro assistente do kubernetes
9. Instalação CNI Callico
10. Lançamento do segundo e terceiro assistentes kubernetes
11. Adicionar um nó de trabalho ao cluster
12. Instalar haproxy nos nós do trabalhador para HA
13. Instalando o Ingress Controller
14. Instalar interface da web (painel)

Lista e destino de hosts

Todos os nós do meu cluster estarão localizados em máquinas virtuais com um sistema extensível Debian 9 pré-instalado com o kernel 4.19.0-0.bpo.5-amd64. Para virtualização, eu uso o Proxmox VE.

Tabela VM e suas características de desempenho:

Não é necessário que você tenha exatamente essa configuração de máquinas, mas ainda assim aconselho a seguir as recomendações da documentação oficial e, para mestres, aumentar a quantidade de RAM para pelo menos 4 GB. Olhando para o futuro, direi que com um número menor, peguei falhas no trabalho da CNI Callico
O Ceph também é bastante voraz em termos de desempenho de memória e disco.
Nossas instalações de produção funcionam sem virtualização bare-metal, mas conheço muitos exemplos em que máquinas virtuais com recursos modestos eram suficientes. Tudo depende de suas necessidades e cargas de trabalho.

Lista e versões de software

A partir da versão 1.14, o Kubeadm parou de oferecer suporte à versão da API v1alpha3 e mudou completamente para a versão da API v1beta1, que será suportada no futuro próximo, portanto, neste artigo, falarei apenas da v1beta1.
Portanto, acreditamos que você preparou as máquinas para o cluster kubernetes. Eles são acessíveis entre si pela rede, têm uma "conexão com a Internet" e um sistema operacional "limpo" instalado.
Para cada etapa da instalação, vou esclarecer em quais máquinas o comando ou bloco de comandos é executado. Execute todos os comandos como root, a menos que especificado de outra forma.
Todos os arquivos de configuração, bem como um script para sua preparação, estão disponíveis para download no meu github
Então, vamos começar.

Diagrama de HA do cluster Kubernetes

Um diagrama aproximado do cluster de alta disponibilidade. O artista meu é mais ou menos assim, para ser honesto, mas tentarei explicar em poucas palavras e de maneira bastante simplista, sem me aprofundar na teoria.
Portanto, nosso cluster consistirá em três nós principais e três nós de trabalho. Em cada nó mestre do kubernetes, etcd (setas verdes no diagrama) e peças de serviço do kubernetes funcionarão para nós; vamos chamá-los genericamente - kubeapi.
Através do cluster mestre etcd, os nós trocam o estado do cluster kubernetes. Indicarei os mesmos endereços dos pontos de entrada do controlador de ingresso para tráfego externo (setas vermelhas no diagrama)
Nos nós do trabalhador, o kubelet funciona para nós, que se comunica com o servidor api do kubernetes por meio do haproxy instalado localmente em cada nó do trabalhador. Como o endereço da API do servidor para o kubelet, usarei o host local 127.0.0.1:6443, e o haproxy no roundrobin dispersará as solicitações em três nós principais, além de verificar a disponibilidade dos nós principais. Esse esquema nos permitirá criar HA e, no caso de falha de um dos nós principais, os nós trabalhadores enviarão silenciosamente solicitações aos dois nós principais restantes.

Antes de começar

Antes de iniciar o trabalho em cada nó do cluster, forneceremos os pacotes que precisaremos para trabalhar:

apt-get update && apt-get install -y curl apt-transport-https git 

Nos nós principais, copie o repositório com modelos de configuração

 sudo -i git clone https://github.com/rjeka/kubernetes-ceph-percona.git 

Verifique se o endereço IP dos hosts nos assistentes corresponde ao endereço no qual o servidor kubernetes escutará

 hostname && hostname -i master01 10.73.71.25 

e assim para todos os nós principais.

Certifique-se de desativar o SWAP, caso contrário, o kubeadm gerará um erro

 [ERROR Swap]: running with swap on is not supported. Please disable swap 

Você pode desativar o comando

 swapoff -a 

Lembre-se de comentar em / etc / fstab

Preencha o arquivo create-config.sh

Para preencher automaticamente as configurações necessárias para instalar o cluster kubernetes, enviei um pequeno script create-config.sh. Você precisa preenchê-lo literalmente 8 linhas. Indique os endereços IP e o nome do host de seus mestres. E também especifique etcd tocken, você não pode alterá-lo. Darei a seguir a parte do script na qual você precisa fazer alterações.

 #!/bin/bash ####################################### # all masters settings below must be same ####################################### # master01 ip address export K8SHA_IP1=10.73.71.25 # master02 ip address export K8SHA_IP2=10.73.71.26 # master03 ip address export K8SHA_IP3=10.73.71.27 # master01 hostname export K8SHA_HOSTNAME1=master01 # master02 hostname export K8SHA_HOSTNAME2=master02 # master03 hostname export K8SHA_HOSTNAME3=master03 #etcd tocken: export ETCD_TOKEN=9489bf67bdfe1b3ae077d6fd9e7efefd #etcd version export ETCD_VERSION="v3.3.10" 

Atualização do kernel do SO

Esta etapa é opcional, pois o kernel precisará ser atualizado pelas portas traseiras, e você faz isso por seu próprio risco e risco. Talvez você nunca encontre esse problema e, se encontrar, poderá atualizar o kernel mesmo após a implantação do kubernetes. Em geral, você decide.
É necessária uma atualização do kernel para corrigir o bug do docker antigo, que foi corrigido apenas na versão 4.18 do kernel do linux. Você pode ler mais sobre esse bug aqui . Um erro foi expresso no travamento periódico da interface de rede nos nós do kubernetes com o erro:

 waiting for eth0 to become free. Usage count = 1 

Depois de instalar o SO, tive a versão 4.9 do kernel

 uname -a Linux master01 4.9.0-7-amd64 #1 SMP Debian 4.9.110-3+deb9u2 (2018-08-13) x86_64 GNU/Linux 

Em cada máquina para kubernetes, executamos
Etapa 1
Adicionar portas de volta à lista de fontes

 echo deb http://ftp.debian.org/debian stretch-backports main > /etc/apt/sources.list apt-get update apt-cache policy linux-compiler-gcc-6-x86 

Etapa número 2
Instalação do pacote

 apt install -y -t stretch-backports linux-image-amd64 linux-headers-amd64 

Etapa número 3
Reiniciar

 reboot 

Verifique se está tudo bem

 uname -a Linux master01 4.19.0-0.bpo.5-amd64 #1 SMP Debian 4.19.37-4~bpo9+1 (2019-06-19) x86_64 GNU/Linux 

Preparando nós Instalando o Kubelet, Kubectl, Kubeadm e Docker

Instale Kubelet, Kubectl, Kubeadm

Colocamos todos os nós do cluster, de acordo com a documentação dos kubernetes

 apt-get update && apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - cat <<EOF >/etc/apt/sources.list.d/kubernetes.list deb https://apt.kubernetes.io/ kubernetes-xenial main EOF apt-get update apt-get install -y kubelet kubeadm kubectl apt-mark hold kubelet kubeadm kubectl 

Instalar o Docker

Instale a janela de encaixe de acordo com as instruções da documentação

 apt-get remove docker docker-engine docker.io containerd runc apt-get install apt-transport-https ca-certificates curl gnupg2 software-properties-common 

 curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add - apt-key fingerprint 0EBFCD88 

 add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/debian \ $(lsb_release -cs) \ stable" 

 apt-get update apt-get install docker-ce docker-ce-cli containerd.io 

 git clone https://github.com/rjeka/kubernetes-ceph-percona.git cd kubernetes-ceph-percona/playbooks vim masters.ini 

 # sudo c  ansible-playbook -i hosts.ini kubelet.yaml -K ansible-playbook -i hosts.ini docker.yaml -K # sudo  ansible-playbook -i hosts.ini kubelet.yaml ansible-playbook -i hosts.ini docker.yaml 

Se, por algum motivo, você não quiser usar a janela de encaixe, poderá usar qualquer CRI. Você pode ler sobre isso, por exemplo, aqui , mas este tópico está além do escopo deste artigo.

Instalação do ETCD

Não vou aprofundar a teoria, em poucas palavras: etcd é um armazenamento de valor-chave distribuído de código aberto. O etcd é escrito no GO e usado no kubernetes de fato, como um banco de dados para armazenar o status do cluster. Para uma revisão mais detalhada, consulte a documentação do kubernetes .
O etcd pode ser instalado de várias maneiras. Você pode instalá-lo localmente e executar como um daemon, você pode executá-lo em contêineres de encaixe, você pode instalá-lo mesmo como parte inferior do kubernetes. Você pode instalá-lo manualmente ou instalá-lo usando o kubeadm (eu não tentei esse método). Pode ser instalado em máquinas de cluster ou servidores individuais.
Instalarei o etcd localmente nos nós principais e executarei como um daemon através do systemd, além de considerar a instalação no docker. Eu uso o etcd sem TLS, se você precisar do TLS, consulte a documentação do etcd ou do próprio kubernetes
Também no meu github estará o ansible-playbook para instalar o etcd com o lançamento pelo systemd.

Opção número 1
Instale localmente, execute o systemd

Em todos os mestres: (nos nós de trabalho do cluster, esta etapa não é necessária)
Etapa 1
Faça o download e descompacte o arquivo com o etcd:

 mkdir archives cd archives export etcdVersion=v3.3.10 wget https://github.com/coreos/etcd/releases/download/$etcdVersion/etcd-$etcdVersion-linux-amd64.tar.gz tar -xvf etcd-$etcdVersion-linux-amd64.tar.gz -C /usr/local/bin/ --strip-components=1 

Etapa número 2
Crie um arquivo de configuração para ETCD

 cd .. ./create-config.sh etcd 

O script aceita o valor etcd como uma entrada e gera um arquivo de configuração no diretório etcd. Após a execução do script, o arquivo de configuração finalizado estará localizado no diretório etcd.
Para todas as outras configurações, o script funciona com o mesmo princípio. É preciso alguma entrada e cria uma configuração em um diretório específico.

Etapa número 3
Iniciamos o cluster etcd e verificamos seu desempenho

 systemctl start etcd 

Verificando o desempenho do daemon

 systemctl status etcd ● etcd.service - etcd Loaded: loaded (/etc/systemd/system/etcd.service; disabled; vendor preset: enabled) Active: active (running) since Sun 2019-07-07 02:34:28 MSK; 4min 46s ago Docs: https://github.com/coreos/etcd Main PID: 7471 (etcd) Tasks: 14 (limit: 4915) CGroup: /system.slice/etcd.service └─7471 /usr/local/bin/etcd --name master01 --data-dir /var/lib/etcd --listen-client-urls http://0.0.0.0:2379,http://0.0.0.0:4001 --advertise-client-urls http://10.73.71.25:2379,http://10.73.71. Jul 07 02:34:28 master01 etcd[7471]: b11e73358a31b109 [logterm: 1, index: 3, vote: 0] cast MsgVote for f67dd9aaa8a44ab9 [logterm: 2, index: 5] at term 554 Jul 07 02:34:28 master01 etcd[7471]: raft.node: b11e73358a31b109 elected leader f67dd9aaa8a44ab9 at term 554 Jul 07 02:34:28 master01 etcd[7471]: published {Name:master01 ClientURLs:[http://10.73.71.25:2379 http://10.73.71.25:4001]} to cluster d0979b2e7159c1e6 Jul 07 02:34:28 master01 etcd[7471]: ready to serve client requests Jul 07 02:34:28 master01 etcd[7471]: serving insecure client requests on [::]:4001, this is strongly discouraged! Jul 07 02:34:28 master01 systemd[1]: Started etcd. Jul 07 02:34:28 master01 etcd[7471]: ready to serve client requests Jul 07 02:34:28 master01 etcd[7471]: serving insecure client requests on [::]:2379, this is strongly discouraged! Jul 07 02:34:28 master01 etcd[7471]: set the initial cluster version to 3.3 Jul 07 02:34:28 master01 etcd[7471]: enabled capabilities for version 3.3 lines 1-19 

E a saúde do próprio cluster:

 etcdctl cluster-health member 61db137992290fc is healthy: got healthy result from http://10.73.71.27:2379 member b11e73358a31b109 is healthy: got healthy result from http://10.73.71.25:2379 member f67dd9aaa8a44ab9 is healthy: got healthy result from http://10.73.71.26:2379 cluster is healthy etcdctl member list 61db137992290fc: name=master03 peerURLs=http://10.73.71.27:2380 clientURLs=http://10.73.71.27:2379,http://10.73.71.27:4001 isLeader=false b11e73358a31b109: name=master01 peerURLs=http://10.73.71.25:2380 clientURLs=http://10.73.71.25:2379,http://10.73.71.25:4001 isLeader=false f67dd9aaa8a44ab9: name=master02 peerURLs=http://10.73.71.26:2380 clientURLs=http://10.73.71.26:2379,http://10.73.71.26:4001 isLeader=true 

 git clone https://github.com/rjeka/kubernetes-ceph-percona.git cd kubernetes-ceph-percona/playbooks vim masters.ini 

 # sudo c  ansible-playbook -i hosts.ini -l masters etcd.yaml -K BECOME password: <sudo > # sudo  ansible-playbook -i hosts.ini -l masters etcd.yaml 

Se você deseja executar o etcd na janela de encaixe, há uma instrução sob o spoiler.

 git clone https://github.com/rjeka/kubernetes-ceph-percona.git cd kubernetes-ceph-percona 

 apt-get install -y docker-compose 

 ./create-config.sh docker 

 docker-compose --file etcd-docker/docker-compose.yaml up -d 

 docker ps 

 root@master01:~/kubernetes-ceph-percona# docker exec -ti etcd etcdctl cluster-health member 61db137992290fc is healthy: got healthy result from http://10.73.71.27:2379 member b11e73358a31b109 is healthy: got healthy result from http://10.73.71.25:2379 member f67dd9aaa8a44ab9 is healthy: got healthy result from http://10.73.71.26:2379 cluster is healthy root@master01:~/kubernetes-ceph-percona# docker exec -ti etcd etcdctl member list 61db137992290fc: name=etcd3 peerURLs=http://10.73.71.27:2380 clientURLs=http://10.73.71.27:2379,http://10.73.71.27:4001 isLeader=false b11e73358a31b109: name=etcd1 peerURLs=http://10.73.71.25:2380 clientURLs=http://10.73.71.25:2379,http://10.73.71.25:4001 isLeader=true f67dd9aaa8a44ab9: name=etcd2 peerURLs=http://10.73.71.26:2380 clientURLs=http://10.73.71.26:2379,http://10.73.71.26:4001 isLeader=false 

 docker logs etcd 

Iniciando o primeiro assistente do kubernetes

Primeiro de tudo, precisamos gerar uma configuração para o kubeadmin

 ./create-config.sh kubeadm 

 apiVersion: kubeadm.k8s.io/v1beta1 kind: InitConfiguration localAPIEndpoint: advertiseAddress: 10.73.71.25 #    API- --- apiVersion: kubeadm.k8s.io/v1beta1 kind: ClusterConfiguration kubernetesVersion: stable #      apiServer: #    kubeadm   certSANs: - 127.0.0.1 - 10.73.71.25 - 10.73.71.26 - 10.73.71.27 controlPlaneEndpoint: 10.73.71.25 #     etcd: #  etc external: endpoints: - http://10.73.71.25:2379 - http://10.73.71.26:2379 - http://10.73.71.27:2379 networking: podSubnet: 192.168.0.0/16 #   ,   CNI  . 

Iniciamos o primeiro mestre

 kubeadm init --config=kubeadmin/kubeadm-init.yaml 

Se o kubeadm funcionar sem erros, na saída obteremos aproximadamente a seguinte saída:

 You can now join any number of control-plane nodes by copying certificate authorities and service account keys on each node and then running the following as root: kubeadm join 10.73.71.25:6443 --token ivwoap.259retezqf34amx8 \ --discovery-token-ca-cert-hash sha256:b5c93e32457c8e6478782ff62e8ef77acf72738dda59cd603cdf4821abe12ca3 \ --control-plane Then you can join any number of worker nodes by running the following on each as root: kubeadm join 10.73.71.25:6443 --token ivwoap.259retezqf34amx8 \ --discovery-token-ca-cert-hash sha256:b5c93e32457c8e6478782ff62e8ef77acf72738dda59cd603cdf4821abe12ca3 

Instalação da CNI Calico

Chegou a hora de estabelecer uma rede na qual nossos pods funcionem. Eu uso chita, e vamos colocá-lo.
E para iniciantes, configure o acesso ao kubelet. Executamos todos os comandos no master01
Se você estiver executando como root

 export KUBECONFIG=/etc/kubernetes/admin.conf 

Se sob o usuário simples

 mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config 

Você também pode gerenciar o cluster no seu laptop ou em qualquer máquina local. Para fazer isso, copie o arquivo /etc/kubernetes/admin.conf para o seu laptop ou qualquer outra máquina em $ HOME / .kube / config

Colocamos a CNI de acordo com a documentação do Kubernetes

 kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml 

Esperamos até que todos os pods subam

 watch -n1 kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system calico-kube-controllers-59f54d6bbc-psr2z 1/1 Running 0 96s kube-system calico-node-hm49z 1/1 Running 0 96s kube-system coredns-5c98db65d4-svcx9 1/1 Running 0 77m kube-system coredns-5c98db65d4-zdlb8 1/1 Running 0 77m kube-system kube-apiserver-master01 1/1 Running 0 76m kube-system kube-controller-manager-master01 1/1 Running 0 77m kube-system kube-proxy-nkdqn 1/1 Running 0 77m kube-system kube-scheduler-master01 1/1 Running 0 77m 

Lançamento do segundo e terceiro assistentes kubernetes

Antes de iniciar o master02 e o master03, é necessário copiar os certificados com o master01 que o kubeadm gerou ao criar o cluster. Vou copiar via scp
Em master01

 export master02=10.73.71.26 export master03=10.73.71.27 scp -r /etc/kubernetes/pki $master02:/etc/kubernetes/ scp -r /etc/kubernetes/pki $master03:/etc/kubernetes/ 

Em master02 e master03
Crie uma configuração para o kubeadm

 ./create-config.sh kubeadm 

E adicione master02 e master03 ao cluster

 kubeadm init --config=kubeadmin/kubeadm-init.yaml 

 root@master01:~/kubernetes-ceph-percona# kubectl get pods -A -w NAMESPACE NAME READY STATUS RESTARTS AGE kube-system calico-kube-controllers-658558ddf8-t6gfs 0/1 ContainerCreating 0 11s kube-system calico-node-7td8g 1/1 Running 0 11s kube-system calico-node-dthg5 0/1 CrashLoopBackOff 1 11s kube-system calico-node-tvhkq 0/1 CrashLoopBackOff 1 11s 

 kubectl edit -n kube-system ds calico-node 

 - name: IP_AUTODETECTION_METHOD value: ens19 

 # kubectl get nodes NAME STATUS ROLES AGE VERSION master01 Ready master 28m v1.15.1 master02 Ready master 26m v1.15.1 master03 Ready master 18m v1.15.1 

 # kubectl get pods -A -o wide | grep calico kube-system calico-kube-controllers-59f54d6bbc-5lxgn 1/1 Running 0 27m kube-system calico-node-fngpz 1/1 Running 1 24m kube-system calico-node-gk7rh 1/1 Running 0 8m55s kube-system calico-node-w4xtt 1/1 Running 0 25m 

Adicionar nós de trabalho ao cluster

No momento, temos um cluster no qual três nós principais estão em execução. Mas nós principais são máquinas executando API, agendador e outros serviços do cluster kubernetes. Para podermos executar nossos pods, precisamos dos chamados nós de trabalho.
Se você tem recursos limitados, pode executar pods em nós principais, mas pessoalmente não aconselho fazer isso.

 kubectl taint nodes --all node-role.kubernetes.io/master- 

Instale os nós kubelet, kubeadm, kubectl e docker no trabalhador e nos nós principais

 apt-get update && apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - cat <<EOF >/etc/apt/sources.list.d/kubernetes.list deb https://apt.kubernetes.io/ kubernetes-xenial main EOF apt-get update apt-get install -y kubelet kubeadm kubectl apt-mark hold kubelet kubeadm kubectl 

 apt-get remove docker docker-engine docker.io containerd runc apt-get install apt-transport-https ca-certificates curl gnupg2 software-properties-common 

 curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add - apt-key fingerprint 0EBFCD88 

 add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/debian \ $(lsb_release -cs) \ stable" 

 apt-get update apt-get install docker-ce docker-ce-cli containerd.io 

 git clone https://github.com/rjeka/kubernetes-ceph-percona.git cd kubernetes-ceph-percona/playbooks vim masters.ini 

 # sudo c  ansible-playbook -i hosts.ini kubelet.yaml -K ansible-playbook -i hosts.ini docker.yaml -K # sudo  ansible-playbook -i hosts.ini kubelet.yaml ansible-playbook -i hosts.ini docker.yaml 

Agora é hora de retornar à linha que o kubeadm gerou quando instalamos o nó principal.
Ela parece assim para mim.

 kubeadm join 10.73.71.25:6443 --token ivwoap.259retezqf34amx8 \ --discovery-token-ca-cert-hash sha256:b5c93e32457c8e6478782ff62e8ef77acf72738dda59cd603cdf4821abe12ca3 

É necessário executar este comando em cada nó do trabalhador.
Se você não tiver escrito um token, poderá gerar um novo

 kubeadm token create --print-join-command --ttl=0 

Depois que o kubeadm funciona, seu novo nó é inserido no cluster e pronto para o trabalho

 This node has joined the cluster: * Certificate signing request was sent to apiserver and a response was received. * The Kubelet was informed of the new secure connection details. Run 'kubectl get nodes' on the control-plane to see this node join the cluster. 

Agora vamos ver o resultado

 root@master01:~# kubectl get nodes NAME STATUS ROLES AGE VERSION master01 Ready master 10d v1.15.1 master02 Ready master 10d v1.15.1 master03 Ready master 10d v1.15.1 worknode01 Ready <none> 5m44s v1.15.1 worknode02 Ready <none> 59s v1.15.1 worknode03 Ready <none> 51s v1.15.1 

Instalar haproxy em nós de trabalho

Agora, temos um cluster de trabalho com três nós principais e três nós de trabalho.
O problema é que agora nossos nós de trabalho não têm o modo HA.
Se você observar o arquivo de configuração do kubelet, veremos que nossos nós de trabalho acessam apenas um dos três nós principais.

 root@worknode01:~# cat /etc/kubernetes/kubelet.conf | grep server: server: https://10.73.71.27:6443 

No meu caso, isso é master03. Com essa configuração, se o master03 travar, o nó do trabalhador perderá a comunicação com o servidor da API do cluster. Para tornar nosso cluster totalmente HA, instalaremos um Load Balancer (Haproxy) em cada um dos trabalhadores, que, de acordo com o round robin, espalhará solicitações para três nós principais e, na configuração do kubelet nos nós de trabalhadores, alteraremos o endereço do servidor para 127.0.0.1:6443
Primeiro, instale o HAProxy em cada nó do trabalhador.
Há uma boa folha de dicas para instalação

 curl https://haproxy.debian.net/bernat.debian.org.gpg | \ apt-key add - echo deb http://haproxy.debian.net stretch-backports-2.0 main | \ tee /etc/apt/sources.list.d/haproxy.list apt-get update apt-get install haproxy=2.0.\* 

Após a instalação do HAproxy, precisamos criar uma configuração para ele.
Se nos nós de trabalho não houver um diretório com os arquivos de configuração, nós o clonaremos

 git clone https://github.com/rjeka/kubernetes-ceph-percona.git cd kubernetes-ceph-percona/ 

E execute o script de configuração com o sinalizador haproxy

 ./create-config.sh haproxy 

O script irá configurar e reiniciar o haproxy.
Verifique se o haproxy começou a ouvir a porta 6443.

 root@worknode01:~/kubernetes-ceph-percona# netstat -alpn | grep 6443 tcp 0 0 127.0.0.1:6443 0.0.0.0:* LISTEN 30675/haproxy tcp 0 0 10.73.75.241:6443 0.0.0.0:* LISTEN 30675/haproxy 

Agora precisamos dizer ao kubelet para acessar o host local em vez do nó mestre. Para fazer isso, edite o valor do servidor nos arquivos /etc/kubernetes/kubelet.conf e /etc/kubernetes/bootstrap-kubelet.conf em todos os nós do trabalhador.

 vim /etc/kubernetes/kubelet.conf vim nano /etc/kubernetes/bootstrap-kubelet.conf 

O valor do servidor deve assumir este formulário:

 server: https://127.0.0.1:6443 

Após fazer as alterações, reinicie os serviços kubelet e docker

 systemctl restart kubelet && systemctl restart docker 

Verifique se todos os nós estão funcionando corretamente.

 kubectl get nodes NAME STATUS ROLES AGE VERSION master01 Ready master 29m v1.15.1 master02 Ready master 27m v1.15.1 master03 Ready master 26m v1.15.1 worknode01 Ready <none> 25m v1.15.1 worknode02 Ready <none> 3m15s v1.15.1 worknode03 Ready <none> 3m16s v1.15.1 

Até o momento, não temos aplicativos no cluster para testar a HA. Mas podemos parar a operação do kubelet no primeiro nó principal e garantir que nosso cluster permaneça operacional.

 systemctl stop kubelet && systemctl stop docker 

Verifique a partir do segundo nó principal

 root@master02:~# kubectl get nodes NAME STATUS ROLES AGE VERSION master01 NotReady master 15h v1.15.1 master02 Ready master 15h v1.15.1 master03 Ready master 15h v1.15.1 worknode01 Ready <none> 15h v1.15.1 worknode02 Ready <none> 15h v1.15.1 worknode03 Ready <none> 15h v1.15.1 

Todos os nós funcionam normalmente, exceto aquele em que paramos os serviços.
Não se esqueça de retornar os serviços kubernetes no primeiro nó principal

 systemctl start kubelet && systemctl start docker 

Instalando o Ingress Controller

O controlador do Ingress é o complemento do Kubernetes, com o qual podemos acessar nossos aplicativos de fora. Uma descrição detalhada está na documentação do Kuberbnetes . Existem muitos controladores de entrada, eu uso um controlador da Nginx. Eu vou falar sobre a instalação dele. A documentação sobre operação, configuração e instalação do controlador Ingress da Nginx pode ser lida no site oficial

Vamos começar a instalação, todos os comandos podem ser executados com master01.
Instale o próprio controlador

 kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml 

E agora - um serviço através do qual a entrada estará disponível
Para fazer isso, prepare a configuração

 ./create-config.sh ingress 

E envie para o nosso cluster

 kubectl apply -f ingress/service-nodeport.yaml 

Verifique se o nosso Ingress funciona nos endereços corretos e escuta nas portas corretas.

 # kubectl get svc -n ingress-nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ingress-nginx NodePort 10.99.35.95 10.73.71.25,10.73.71.26,10.73.71.27 80:31669/TCP,443:31604/TCP 10m 

  kubectl describe svc -n ingress-nginx ingress-nginx Name: ingress-nginx Namespace: ingress-nginx Labels: app.kubernetes.io/name=ingress-nginx app.kubernetes.io/part-of=ingress-nginx Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app.kubernetes.io/name":"ingress-nginx","app.kubernetes.io/par... Selector: app.kubernetes.io/name=ingress-nginx,app.kubernetes.io/part-of=ingress-nginx Type: NodePort IP: 10.99.35.95 External IPs: 10.73.71.25,10.73.71.26,10.73.71.27 Port: http 80/TCP TargetPort: 80/TCP NodePort: http 31669/TCP Endpoints: 192.168.142.129:80 Port: https 443/TCP TargetPort: 443/TCP NodePort: https 31604/TCP Endpoints: 192.168.142.129:443 Session Affinity: None External Traffic Policy: Cluster Events: <none> 

Instalar interface da web (painel)

O Kubernetes possui uma interface de usuário da Web padrão, por meio da qual às vezes é conveniente examinar rapidamente o estado de um cluster ou suas partes individuais. No meu trabalho, costumo usar o painel para o diagnóstico inicial de implantações ou o estado de partes de um cluster.
O link para a documentação está no site kubernetes
Instalação Estou usando a versão estável, ainda não tentei o 2.0.

 #  kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml # 2.0 kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta1/aio/deploy/recommended.yaml 

Depois de instalar o painel em nosso cluster, o painel ficou disponível em

 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/. 

Mas, para conseguir isso, precisamos encaminhar portas da máquina local usando o proxy kubectl. Para mim, esse esquema não é muito conveniente. Portanto, alterarei o serviço do painel de controle para que o painel fique disponível no endereço de qualquer nó do cluster na porta 30443. Ainda existem outras maneiras de acessar o painel, por exemplo, através da entrada. Talvez eu considere esse método nas seguintes publicações.
Para alterar o serviço, execute a implantação do serviço alterado

 kubectl apply -f dashboard/service-nodeport.yaml 

Resta criar o usuário e o token de administrador para acessar o cluster por meio do painel

 kubectl apply -f dashboard/rbac.yaml kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}') 

Depois disso, você pode fazer login no painel de controle em https://10.73.71.25:30443

Tela inicial do painel

Parabéns! Se você atingiu esta etapa, possui um cluster de HA de kubernetes em funcionamento, pronto para a implantação de seus aplicativos.
Kubernetes , . .
, GitHub, , .
C , .