Implantar a HA do kubernetes com o container

Boa tarde, queridos leitores de Habr! Em 24 de maio de 2018, um artigo intitulado Kubernetes Containerd Integration Goes GA foi publicado no blog oficial da Kubernetes, que declara que a integração da containererd com o Kubernetes está pronta para produção. Além disso, os caras da empresa Flant postaram uma tradução do artigo para o russo em seu blog, acrescentando alguns esclarecimentos. Depois de ler a documentação do projeto no github , decidi tentar conter "minha própria pele".

Nossa empresa tem vários projetos na fase de "ainda muito longe da produção". Então eles se tornarão nosso experimental; Para eles, decidimos tentar implantar um cluster de failover do Kubernetes usando o containerd e ver se há vida útil sem o docker.

Se você estiver interessado em ver como fizemos e o que aconteceu, seja bem-vindo ao gato.

Descrição esquemática e de implantação

Ao implantar um cluster, como de costume, (escrevi sobre isso em um artigo anterior

Os daemons mantidos vivos se comunicam via VRRP, enviando mensagens para o endereço 224.0.0.18.

Se o vizinho não enviou sua mensagem, depois do período, ele é considerado morto. Assim que o servidor travado começa a enviar suas mensagens para a rede, tudo volta ao seu lugar

Configuramos o trabalho com o servidor API nos nós do kubernetes da seguinte maneira.

Após instalar o cluster, configure o kube-proxy, altere a porta de 6443 para 16443 (detalhes abaixo). Em cada um dos mestres, o nginx é implementado, que funciona como um balanceador de carga, escuta na porta 16443 e faz um upstream de todos os três mestres na porta 6443 (detalhes abaixo).

Esse esquema alcançou maior tolerância a falhas usando keepalived e nginx, foi alcançado o equilíbrio entre os servidores API nos assistentes.

Em um artigo anterior, descrevi a implantação do nginx e etcd na janela de encaixe. Mas, neste caso, não temos docker, portanto, nginx e etcd funcionarão localmente em masternodes.

Teoricamente, seria possível implantar o nginx e etcd usando o containerd, mas em caso de problemas, essa abordagem complicaria o diagnóstico, por isso decidimos não experimentar e executá-lo localmente.

Descrição dos servidores para implantação:

Instale kubeadm, kubelet, kubectl e pacotes relacionados

Todos os comandos são executados a partir da raiz

sudo -i 

 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 http://apt.kubernetes.io/ kubernetes-xenial main EOF apt-get update apt-get install -y kubelet kubeadm kubectl unzip tar apt-transport-https btrfs-tools libseccomp2 socat util-linux mc vim keepalived 

Instalar conteinerd

 cd / wget https://storage.googleapis.com/cri-containerd-release/cri-containerd-1.1.0-rc.0.linux-amd64.tar.gz tar -xvf cri-containerd-1.1.0-rc.0.linux-amd64.tar.gz 

Configurando Configurações de Contêiner

 mkdir -p /etc/containerd nano /etc/containerd/config.toml 

Adicionar ao arquivo:

 [plugins.cri] enable_tls_streaming = true 

Começamos a contarinerd, verificamos que está tudo bem

 systemctl enable containerd systemctl start containerd systemctl status containerd ● containerd.service - containerd container runtime Loaded: loaded (/etc/systemd/system/containerd.service; disabled; vendor preset: enabled) Active: active (running) since Mon 2018-06-25 12:32:01 MSK; 7s ago Docs: https://containerd.io Process: 10725 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS) Main PID: 10730 (containerd) Tasks: 15 (limit: 4915) Memory: 14.9M CPU: 375ms CGroup: /system.slice/containerd.service └─10730 /usr/local/bin/containerd Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="Get image filesystem path "/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs"" Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=error msg="Failed to load cni during init, please check CRI plugin status before setting up network for pods" error="cni con Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="loading plugin "io.containerd.grpc.v1.introspection"..." type=io.containerd.grpc.v1 Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="Start subscribing containerd event" Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="Start recovering state" Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg=serving... address="/run/containerd/containerd.sock" Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="containerd successfully booted in 0.308755s" Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="Start event monitor" Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="Start snapshots syncer" Jun 25 12:32:01 hb-master02 containerd[10730]: time="2018-06-25T12:32:01+03:00" level=info msg="Start streaming server" 

Instale e execute o etcd

Nota importante, eu instalei o cluster do kubernetes versão 1.10. Apenas alguns dias depois, no momento da redação do artigo, foi lançada a versão 1.11. Se você instalar a versão 1.11, defina a variável ETCD_VERSION = "v3.2.17", se 1.10, então ETCD_VERSION = "v3.1.12".

 export ETCD_VERSION="v3.1.12" curl -sSL https://github.com/coreos/etcd/releases/download/${ETCD_VERSION}/etcd-${ETCD_VERSION}-linux-amd64.tar.gz | tar -xzv --strip-components=1 -C /usr/local/bin/ 

Copie configurações do gitahab.

 git clone https://github.com/rjeka/k8s-containerd.git cd k8s-containerd 

Configure as variáveis ​​no arquivo de configuração.

 vim create-config.sh 

 #!/bin/bash # local machine ip address export K8SHA_IPLOCAL=172.26.133.161 # local machine etcd name, options: etcd1, etcd2, etcd3 export K8SHA_ETCDNAME=kube-master01 # local machine keepalived state config, options: MASTER, BACKUP. One keepalived cluster only one MASTER, other's are BACKUP export K8SHA_KA_STATE=MASTER # local machine keepalived priority config, options: 102, 101,100 MASTER must 102 export K8SHA_KA_PRIO=102 # local machine keepalived network interface name config, for example: eth0 export K8SHA_KA_INTF=ens18 ####################################### # all masters settings below must be same ####################################### # master keepalived virtual ip address export K8SHA_IPVIRTUAL=172.26.133.160 # master01 ip address export K8SHA_IP1=172.26.133.161 # master02 ip address export K8SHA_IP2=172.26.133.162 # master03 ip address export K8SHA_IP3=172.26.133.163 # master01 hostname export K8SHA_HOSTNAME1=kube-master01 # master02 hostname export K8SHA_HOSTNAME2=kube-master02 # master03 hostname export K8SHA_HOSTNAME3=kube-master03 # keepalived auth_pass config, all masters must be same export K8SHA_KA_AUTH=56cf8dd754c90194d1600c483e10abfr #etcd tocken: export ETCD_TOKEN=9489bf67bdfe1b3ae077d6fd9e7efefd # kubernetes cluster token, you can use 'kubeadm token generate' to get a new one export K8SHA_TOKEN=535tdi.utzk5hf75b04ht8l # kubernetes CIDR pod subnet, if CIDR pod subnet is "10.244.0.0/16" please set to "10.244.0.0\\/16" export K8SHA_CIDR=10.244.0.0\\/16 

Execute o script que irá configurar nginx, keepalived, etcd e kubeadmin

 ./create-config.sh 

Começamos etcd.

 systemctl daemon-reload && systemctl start etcd && systemctl enable etcd 

Verificação de status

 etcdctl cluster-health member ad059013ec46f37 is healthy: got healthy result from http://192.168.5.49:2379 member 4d63136c9a3226a1 is healthy: got healthy result from http://192.168.4.169:2379 member d61978cb3555071e is healthy: got healthy result from http://192.168.4.170:2379 cluster is healthy etcdctl member list ad059013ec46f37: name=hb-master03 peerURLs=http://192.168.5.48:2380 clientURLs=http://192.168.5.49:2379,http://192.168.5.49:4001 isLeader=false 4d63136c9a3226a1: name=hb-master01 peerURLs=http://192.168.4.169:2380 clientURLs=http://192.168.4.169:2379,http://192.168.4.169:4001 isLeader=true d61978cb3555071e: name=hb-master02 peerURLs=http://192.168.4.170:2380 clientURLs=http://192.168.4.170:2379,http://192.168.4.170:4001 isLeader=false 

Se tudo estiver bem, prossiga para a próxima etapa.

Configurar o kubeadmin
Se você estiver usando o kubeadm versão 1.11, poderá pular esta etapa
Para que o kybernetes comece a trabalhar não com o docker, mas com o containererderd, configure a configuração do kubeadmin

 vim /etc/systemd/system/kubelet.service.d/10-kubeadm.conf 

Após [Serviço], adicione uma linha ao bloco

 Environment="KUBELET_EXTRA_ARGS=--runtime-cgroups=/system.slice/containerd.service --container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///run/containerd/containerd.sock" 

 [Service] Environment="KUBELET_EXTRA_ARGS=--runtime-cgroups=/system.slice/containerd.service --container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///run/containerd/containerd.sock" Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf" Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true" Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin" Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local" Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt" Environment="KUBELET_CADVISOR_ARGS=--cadvisor-port=0" Environment="KUBELET_CERTIFICATE_ARGS=--rotate-certificates=true --cert-dir=/var/lib/kubelet/pki" ExecStart= ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_CADVISOR_ARGS $KUBELET_CERTIFICATE_ARGS $KUBELET_EXTRA_ARGS 

Se você instalar a versão 1.11 e quiser experimentar o CoreDNS em vez do kube-dns e testar a configuração dinâmica, remova o comentário do seguinte bloco no arquivo de configuração kubeadm-init.yaml:

 feature-gates: DynamicKubeletConfig: true CoreDNS: true 

Reinicie o kubelet

 systemctl daemon-reload && systemctl restart kubelet 

Inicialização do primeiro assistente

Antes de iniciar o kubeadm, você precisa reiniciar o keepalived e verificar seu status

 systemctl restart keepalived.service systemctl status keepalived.service ● keepalived.service - Keepalive Daemon (LVS and VRRP) Loaded: loaded (/lib/systemd/system/keepalived.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2018-06-27 10:40:03 MSK; 1min 44s ago Process: 4589 ExecStart=/usr/sbin/keepalived $DAEMON_ARGS (code=exited, status=0/SUCCESS) Main PID: 4590 (keepalived) Tasks: 7 (limit: 4915) Memory: 15.3M CPU: 968ms CGroup: /system.slice/keepalived.service ├─4590 /usr/sbin/keepalived ├─4591 /usr/sbin/keepalived ├─4593 /usr/sbin/keepalived ├─5222 /usr/sbin/keepalived ├─5223 sh -c /etc/keepalived/check_apiserver.sh ├─5224 /bin/bash /etc/keepalived/check_apiserver.sh └─5231 sleep 5 

verifique se VIRTIP pings

 ping -c 4 172.26.133.160 PING 172.26.133.160 (172.26.133.160) 56(84) bytes of data. 64 bytes from 172.26.133.160: icmp_seq=1 ttl=64 time=0.030 ms 64 bytes from 172.26.133.160: icmp_seq=2 ttl=64 time=0.050 ms 64 bytes from 172.26.133.160: icmp_seq=3 ttl=64 time=0.050 ms 64 bytes from 172.26.133.160: icmp_seq=4 ttl=64 time=0.056 ms --- 172.26.133.160 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3069ms rtt min/avg/max/mdev = 0.030/0.046/0.056/0.012 ms 

Depois disso, execute o kubeadmin. Certifique-se de incluir a linha --skip-preflight-checks. Por padrão, o Kubeadmin procura por janela de encaixe e sem ignorar as verificações falhará com um erro.

 kubeadm init --config=kubeadm-init.yaml --skip-preflight-checks 

Após o kubeadm funcionar, salve a linha gerada. Será necessário inserir nós de trabalho no cluster.

 kubeadm join 172.26.133.160:6443 --token XXXXXXXXXXXXXXXXXXXXXXXXX --discovery-token-ca-cert-hash sha256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

Em seguida, indique onde o arquivo admin.conf está armazenado
Se trabalharmos como root, então:

 vim ~/.bashrc export KUBECONFIG=/etc/kubernetes/admin.conf source ~/.bashrc 

Para um usuário simples, siga as instruções na tela.

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

Adicione mais 2 assistentes ao cluster. Para fazer isso, copie os certificados de kube-master01 para kube-master02 e kube-master03 no diretório / etc / kubernetes /. Para fazer isso, configurei o acesso ssh para root e, depois de copiar os arquivos, retornei as configurações.

 scp -r /etc/kubernetes/pki 172.26.133.162:/etc/kubernetes/ scp -r /etc/kubernetes/pki 172.26.133.163:/etc/kubernetes/ 

Após copiar para o kube-master02 e o kube-master03, execute.

 kubeadm init --config=kubeadm-init.yaml --skip-preflight-checks 

Instalar flanela CIDR

no kube-master01 execute

 kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.10.0/Documentation/kube-flannel.yml 

A versão atual do flanel pode ser encontrada na documentação do kubernetes .

Aguardamos até que todos os contêineres sejam criados.

 watch -n1 kubectl get pods --all-namespaces -o wide NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE kube-system kube-apiserver-kube-master01 1/1 Running 0 17m 172.26.133.161 kube-master01 kube-system kube-apiserver-kube-master02 1/1 Running 0 6m 172.26.133.162 kube-master02 kube-system kube-apiserver-kube-master03 1/1 Running 0 6m 172.26.133.163 kube-master03 kube-system kube-controller-manager-kube-master01 1/1 Running 0 17m 172.26.133.161 kube-master01 kube-system kube-controller-manager-kube-master02 1/1 Running 0 6m 172.26.133.162 kube-master02 kube-system kube-controller-manager-kube-master03 1/1 Running 0 6m 172.26.133.163 kube-master03 kube-system kube-dns-86f4d74b45-8c24s 3/3 Running 0 17m 10.244.2.2 kube-master03 kube-system kube-flannel-ds-4h4w7 1/1 Running 0 2m 172.26.133.163 kube-master03 kube-system kube-flannel-ds-kf5mj 1/1 Running 0 2m 172.26.133.162 kube-master02 kube-system kube-flannel-ds-q6k4z 1/1 Running 0 2m 172.26.133.161 kube-master01 kube-system kube-proxy-9cjtp 1/1 Running 0 6m 172.26.133.163 kube-master03 kube-system kube-proxy-9sqk2 1/1 Running 0 17m 172.26.133.161 kube-master01 kube-system kube-proxy-jg2pt 1/1 Running 0 6m 172.26.133.162 kube-master02 kube-system kube-scheduler-kube-master01 1/1 Running 0 18m 172.26.133.161 kube-master01 kube-system kube-scheduler-kube-master02 1/1 Running 0 6m 172.26.133.162 kube-master02 kube-system kube-scheduler-kube-master03 1/1 Running 0 6m 172.26.133.163 kube-master03 

Fazemos a replicação do kube-dns para todos os três mestres

No kube-master01, execute

 kubectl scale --replicas=3 -n kube-system deployment/kube-dns 

Instale e configure o nginx

Em cada nó principal, instale o nginx como um balanceador para a API do Kubernetes
Eu tenho todas as máquinas de cluster no debian. Dos pacotes nginx, o módulo stream não suporta, portanto, adicione os repositórios nginx e instale-o a partir dos repositórios nginx`a. Se você tiver um sistema operacional diferente, consulte a documentação do nginx .

 wget https://nginx.org/keys/nginx_signing.key sudo apt-key add nginx_signing.key echo -e "\n#nginx\n\ deb http://nginx.org/packages/debian/ stretch nginx\n\ deb-src http://nginx.org/packages/debian/ stretch nginx" >> /etc/apt/sources.list apt-get update && apt-get install nginx -y 

Crie a configuração nginx (se ainda não estiver criada)

 ./create-config.sh 

 log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; #tcp_nopush on; keepalive_timeout 65; #gzip on; include /etc/nginx/conf.d/*.conf; 

 } server { listen 16443; proxy_connect_timeout 1s; proxy_timeout 3s; proxy_pass apiserver; } 

Verificamos que está tudo bem e aplicamos a configuração

 nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful systemctl restart nginx systemctl status nginx ● nginx.service - nginx - high performance web server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2018-06-28 08:48:09 MSK; 22s ago Docs: http://nginx.org/en/docs/ Process: 22132 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS) Main PID: 22133 (nginx) Tasks: 2 (limit: 4915) Memory: 1.6M CPU: 7ms CGroup: /system.slice/nginx.service ├─22133 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf └─22134 nginx: worker process 

Teste o balanceador

 curl -k https://172.26.133.161:16443 | wc -l % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 233 100 233 0 0 12348 0 --:--:-- --:--:-- --:--:-- 12944 

Configure o kube-proxy para funcionar com o balanceador

Após a configuração do balanceador, edite a porta nas configurações do kubernetes.

 kubectl edit -n kube-system configmap/kube-proxy 

Altere as configurações do servidor para https://172.26.133.160:16443
Em seguida, você precisa configurar o kube-proxy para trabalhar com a nova porta

 kubectl get pods --all-namespaces -o wide | grep proxy kube-system kube-proxy-9cjtp 1/1 Running 1 22h 172.26.133.163 kube-master03 kube-system kube-proxy-9sqk2 1/1 Running 1 22h 172.26.133.161 kube-master01 kube-system kube-proxy-jg2pt 1/1 Running 4 22h 172.26.133.162 kube- 

Excluímos todos os pods; após a remoção, eles são recriados automaticamente com as novas configurações

 kubectl delete pod -n kube-system kube-proxy-XXX ```bash    .      ```bash kubectl get pods --all-namespaces -o wide | grep proxy kube-system kube-proxy-hqrsw 1/1 Running 0 33s 172.26.133.161 kube-master01 kube-system kube-proxy-kzvw5 1/1 Running 0 47s 172.26.133.163 kube-master03 kube-system kube-proxy-zzkz5 1/1 Running 0 7s 172.26.133.162 kube-master02 

Incluindo Nós de Trabalho no Cluster

Em cada nota raiz, execute o comando gerado pelo kubeadm

 kubeadm join 172.26.133.160:6443 --token XXXXXXXXXXXXXXXXXXXXXXXXX --discovery-token-ca-cert-hash sha256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX --cri-socket /run/containerd/containerd.sock --skip-preflight-checks 

Se a linha estiver "perdida", você precisará gerar uma nova

 kubeadm token generate kubeadm token create <generated-token> --print-join-command --ttl=0 

Nos nós de trabalho nos arquivos /etc/kubernetes/bootstrap-kubelet.conf e /etc/kubernetes/kubelet.conf
valor da variável do servidor para o nosso virtip

 vim /etc/kubernetes/bootstrap-kubelet.conf server: https://172.26.133.60:16443 vim /etc/kubernetes/kubelet.conf server: https://172.26.133.60:16443 

E reinicie o container e os kubernetes

 systemctl restart containerd kubelet 

Instalação do painel

 kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml 

Crie um usuário com privilégios de administrador:

 kubectl apply -f kube-dashboard/dashboard-adminUser.yaml 

Obtemos o token para entrada:

 kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}') 

Configurando o acesso ao painel via NodePort no VIRTIP

 kubectl -n kube-system edit service kubernetes-dashboard 

Substituímos o valor de type: ClusterIP pelo tipo: NodePort e, na seção port: adicionamos o valor de nodePort: 30000 (ou a porta no intervalo de 30000 a 32000 na qual você deseja que o painel esteja acessível):

O painel está agora disponível em https: // VIRTIP: 30000

Heapster

Em seguida, instale o Heapster, uma ferramenta para obter métricas dos componentes do cluster.

Instalação:

 git clone https://github.com/kubernetes/heapster.git cd heapster kubectl create -f deploy/kube-config/influxdb/ kubectl create -f deploy/kube-config/rbac/heapster-rbac.yaml 

Conclusões

Não notei nenhum problema especial ao trabalhar com o container. Uma vez houve uma falha incompreensível com uma lareira após a remoção da implantação. Kubernetes acreditava que sub foi excluído, mas sub tornou-se um "zumbi tão peculiar. Ele ainda existia no nó, mas no status estendido.

Eu acredito que o Containerd é mais orientado como um tempo de execução do contêiner para o kubernetes. Muito provavelmente, no futuro, como um ambiente para o lançamento de microsserviços no Kubernetes, será possível e necessário usar diferentes ambientes que serão orientados para diferentes tarefas, projetos, etc.

O projeto está se desenvolvendo muito rápido. O Alibaba Cloud começou a usar ativamente o conatinerd e enfatiza que é o ambiente ideal para a movimentação de contêineres.

Segundo os desenvolvedores, a integração do container na plataforma de nuvem do Google Kubernetes agora é equivalente à integração do Docker.

Um bom exemplo do utilitário crictl console . Também darei alguns exemplos do cluster criado:

 kubectl describe nodes | grep "Container Runtime Version:" 

A CLI do Docker não possui os conceitos básicos do Kubernetes, por exemplo, pod e espaço para nome, enquanto o crictl suporta esses conceitos.

 crictl pods 

E, se necessário, podemos observar os contêineres no formato usual, como janela de encaixe

 crictl ps 

Podemos ver as imagens que estão no nó

 crictl images 

Como se viu, a vida sem docker` é :)

É muito cedo para falar sobre bugs e falhas, o cluster trabalha conosco há cerca de uma semana. Em um futuro próximo, o teste será transferido para ele e, em caso de sucesso, provavelmente o suporte de um dos projetos. Existe uma idéia sobre isso para escrever uma série de artigos que abordam os processos do DevOps, como: criar um cluster, configurar um controlador de entrada e movê-lo para separar nós do cluster, automatizar a montagem de imagens, verificar imagens quanto a vulnerabilidades, implantação etc. Enquanto isso, analisaremos a estabilidade do trabalho, procuraremos bugs e desenvolveremos novos produtos.

Além disso, este manual é adequado para implantar um cluster de failover com docker, você só precisa instalar o docker de acordo com as instruções da documentação oficial do Kubernetes e pular as etapas para instalar o container e configurar o kubeadm.

Ou você pode colocar o container e o docker simultaneamente no mesmo host e, como os desenvolvedores garantem, eles funcionarão perfeitamente juntos. Containerd é o ambiente de inicialização do contêiner do konbernetes e o docker é como o docker)))

Talvez um dia minhas mãos cheguem e eu escreverei meu manual para implantar um cluster com HA, pois nos últimos seis meses eu implantei mais de uma dúzia deles e provavelmente seria hora de automatizar o processo.

Além disso, ao escrever este artigo, a versão kubernetes 1.11 foi lançada. Você pode ler sobre as principais alterações no blog Flant ou no blog oficial do kubernetes . Atualizamos os clusters de teste para a versão 1.11 e substituímos o kube-dns pelo CoreDNS. Além disso, eles incluíram a função DynamicKubeletConfig para testar os recursos da atualização dinâmica de configurações.

Materiais utilizados:

• Integração Kubernetes Containerd Goes GA
• Integração de contêineres Kubernetes substituindo o Docker pronto para produção
• containserd github
• Documentação do Kubernetes
• Documentação NGINX

Obrigado por ler até o fim.

Como as informações sobre kubernetes, especialmente sobre clusters que operam em condições reais, são muito escassas no RuNet, indicações de imprecisões são bem-vindas, assim como comentários no esquema geral de implantação de cluster. Vou tentar levá-los em consideração e fazer as correções apropriadas. E estou sempre pronto para responder perguntas nos comentários, no githab e em qualquer rede social indicada no meu perfil.

Atenciosamente, Eugene.