No cruzamento, a orquestra
não é alterada.
Depois que eu estava completamente cansado do Docker Swarm devido à sua pseudo-simplicidade e acabamento constante, trabalho pouco conveniente com sistemas de arquivos distribuídos, interface da Web levemente úmida e funcionalidade estreita, além da falta de suporte à integração imediata do GitLab, foi decidido implantar seu cluster Kubernetes em seu próprio hardware, ou seja, implantando o Rancher Management Server 2.0.
Experiência de instalação, esquema de tolerância a falhas, trabalhando com haProxy e dois painéis sob o gato:
Dados de entrada:Servidor host HP Proliant DL320e Gen8 - 2 peças.
VM Ubuntu Server 16.04, 2Gb de RAM, 2vCPU, 20Gb HDD - 1 pc. em cada host (VM-haProxy).
VM Ubuntu Server 16.04, 4Gb RAM, 4vCPU, 40Gb HDD, 20 Gb SSD - 3 peças. em cada host (VM - * - Cluster).
VM Ubuntu Server 16.04, 4Gb RAM, 4vCPU, 100Gb HDD - 1 pc. em qualquer host (VM-NFS).
Diagrama de rede:
Introdução:O VM-haProxy possui regras de haProxy, fail2ban, iptables a bordo. Atua como um gateway para todas as máquinas por trás dele. Temos dois gateways e todas as máquinas, no caso de perda da comunicação do gateway em seu host, mudarão para outro.
A principal tarefa desses nós (VM-haProxy) é distribuir o acesso ao back-end, equilíbrio, encaminhamento de portas e coleta de estatísticas.
Minha escolha recaiu no haProxy, como uma ferramenta mais focada no equilíbrio e verificação de saúde. Por tudo isso, gosto da sintaxe das diretivas de configuração e trabalho com listas brancas e negras de IP, além de trabalhar com conexão SSL de vários domínios.
Configuração HaProxy:
haproxy.conf com comentários Importante: Todas as máquinas devem se conhecer pelo nome do host.
Manifesto de Marionete add-host-entry.pp para adicionar nomes de host em / etc / hosts class host_entries { host { 'proxy01': ip => '10.10.10.11', } host { 'proxy02': ip => '10.10.10.12', } host { 'master': ip => '10.10.10.100', } host { 'node01': ip => '10.10.10.101', } host { 'node02': ip => '10.10.10.102', } host { 'node03': ip => '10.10.10.103', } host { 'node04': ip => '10.10.10.104', } host { 'node05': ip => '10.10.10.105', } host { 'nfs': ip => '10.10.10.200', } }
O VM-Master-Cluster é a principal máquina de controle. Difere de outros nós no Puppet Master, GlusterFS Server, Rancher Server (contêiner), etcd (contêiner), gerenciador de controle (contêiner). Em caso de desconexão desse host, os serviços de produção continuam funcionando.
VM-Node-Cluster - Nós, Trabalhadores. Máquinas de trabalho cujos recursos serão combinados em um ambiente tolerante a falhas. Nada de interessante.
VM-NFS - servidor NFS (nfs-kernel-server). A principal tarefa é fornecer espaço no buffer. Armazena arquivos de configuração e tudo. Não armazena nada de importante. Sua queda pode ser corrigida lentamente, enquanto se bebe café.
Importante: Todas as máquinas de ambiente devem ter a bordo: docker.io, nfs-common, gluster-server.
manifesto fantoche must-have-packages.pp para instalar o software certo class musthave { package { 'docker.io': ensure => 'installed', } package { 'nfs-common': ensure => 'installed', } package { 'gluster-server': ensure => 'installed', } }
Não descreverei a instalação do nfs-volume e a configuração do GlusterFS, pois ele é generosamente descrito em grandes números.
Se você notar que há discos SSD na descrição da especificação, eles são preparados para a operação do sistema de arquivos distribuídos Gluster. Crie partições e armazenamento em discos de alta velocidade.
Nota De fato, executar um Rancher não requer um ambiente espelhado. Todas as opções acima são minha visão do cluster e uma descrição de quais práticas eu sigo.
Para executar o Rancher, basta
uma máquina, com 4CPU, 4Gb RAM, 10Gb HDD.
5 minutos para Rancher.
No VM-Master-Cluster, fazemos:
sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher
Verifique a disponibilidade:
curl -k https://localhost
Se você viu a API - parabenizo você exatamente pela metade do caminho.
Tendo analisado o diagrama da rede novamente, lembramos que trabalharemos de fora, através do haProxy, na configuração que publicamos no link
rancher.domain.ru , vá em
frente , defina sua senha.
A próxima página é a página de criação de cluster do Kubernetes.
No menu Opções de cluster, selecione Flanela. Não trabalhei com outros provedores de rede. Eu não posso aconselhar.
Vale a pena prestar atenção ao fato de que instalamos as caixas de seleção etcd e Control Plane, a caixa de verificação do trabalhador não está instalada, caso você não planeje usar o gerente no modo de trabalhador.
Trabalhamos dentro da rede local, com o mesmo endereço na NIC, portanto, nos campos Endereço público e interno, indica o mesmo IP.
Copie o código resultante acima, execute-o no console.
Após algum tempo, na interface da web, você verá uma mensagem sobre a adição de um nó. E depois de algum tempo, você iniciará o cluster Kubernetes.
Para adicionar um trabalhador, vá para editar o cluster na interface da web Rancher, você verá o mesmo menu que gera o comando de conexão.
Defina a caixa de seleção apenas para a posição do trabalhador, especifique o IP do futuro trabalhador, copie o comando e execute-o no console do nó que você precisa.
Depois de um tempo, a energia do cluster aumentará, assim como o número de nós.
Instale o Painel Kubernetes:Vá para o menu Projetos / espaços para nome.
Após a instalação, você verá que os namespaces relacionados ao Kubernetes estarão contidos fora dos projetos. Para trabalhar totalmente com esses namespaces, eles devem ser colocados no projeto.
Adicione um projeto, nomeie-o como quiser. Mova os espaços para nome (sistema de gado, ingress-nginx, kube-public, kube-system) para o projeto que você criou usando o menu de contexto “Mover”. Deve ser assim:
Clique diretamente no nome do projeto, você será levado ao painel de controle da carga de trabalho. É aqui que discutiremos como criar um serviço simples.
Clique em "Importar YAML" no canto superior direito. Copie e cole o conteúdo
deste arquivo na caixa de texto da janela que se abre, selecione o espaço de nome “kube-system”, clique em “Importar”.
Depois de algum tempo, o pod kubernetes-dashboard será iniciado.
Vá para a edição do pod, abra o menu de publicação de portas, defina os seguintes valores:
Verifique o acesso no nó em que o pod está sendo executado.
curl -k https://master:9090
Veja a resposta? A publicação está concluída, resta chegar à parte administrativa.
Na página principal do gerenciamento de cluster no Rancher, existem ferramentas muito convenientes, como o kubectl - o console de gerenciamento de cluster e o Kubeconfig File - o arquivo de configuração que contém o endereço da API, ca.crt etc.
Entramos no kubectl e executamos:
kubectl create serviceaccount cluster-admin-dashboard-sa kubectl create clusterrolebinding cluster-admin-dashboard-sa --clusterrole=cluster-admin --serviceaccount=default:cluster-admin-dashboard-sa
Criamos uma conta de serviço com os privilégios mais altos, agora precisamos de um token para acessar o Painel.
Encontre o segredo da conta criada:
kubectl get secret | grep cluster-admin-dashboard-sa
Veremos o nome da conta com um certo hash no final, copiá-lo e executar:
kubectl describe secret cluster-admin-dashboard-sa-$( )
Novamente, lembramos que tudo foi publicado com sucesso por meio do haProxy.
Nós seguimos o link
kubernetes.domain.ru . Digite o token recebido.
Alegrai-vos:
PSO resultado geral seria agradecer ao Rancher por criar uma interface intuitiva, uma instância facilmente implementável, documentação simples, a capacidade de mover-se rapidamente e escalabilidade no nível do cluster. Talvez eu tenha falado com muita clareza no início do post que o Swarm estava cansado de tendências óbvias de desenvolvimento, meio que me fez olhar para o lado e não terminar a rotina chata. Docker criou uma era de desenvolvimento. E julgar esse projeto certamente não é para mim.