spray de cubo
v2.26.0
Se você tiver dúvidas, verifique a documentação em kubespray.io e junte-se a nós no slack do kubernetes, canal #kubespray . Você pode obter seu convite aqui
Abaixo estão várias maneiras de usar o Kubespray para implantar um cluster Kubernetes.
Instale o Ansible de acordo com o guia de instalação do Ansible e execute as seguintes etapas:
# Copy ` ` inventory/sample ` ` as ` ` inventory/mycluster ` `
cp -rfp inventory/sample inventory/mycluster
# Update Ansible inventory file with inventory builder
declare -a IPS=(10.10.1.3 10.10.1.4 10.10.1.5)
CONFIG_FILE=inventory/mycluster/hosts.yaml python3 contrib/inventory_builder/inventory.py ${IPS[@]}
# Review and change parameters under ` ` inventory/mycluster/group_vars ` `
cat inventory/mycluster/group_vars/all/all.yml
cat inventory/mycluster/group_vars/k8s_cluster/k8s-cluster.yml
# Clean up old Kubernetes cluster with Ansible Playbook - run the playbook as root
# The option ` --become ` is required, as for example cleaning up SSL keys in /etc/,
# uninstalling old packages and interacting with various systemd daemons.
# Without --become the playbook will fail to run !
# And be mind it will remove the current kubernetes cluster (if it ' s running)!
ansible-playbook -i inventory/mycluster/hosts.yaml --become --become-user=root reset.yml
# Deploy Kubespray with Ansible Playbook - run the playbook as root
# The option ` --become ` is required, as for example writing SSL keys in /etc/,
# installing packages and interacting with various systemd daemons.
# Without --become the playbook will fail to run !
ansible-playbook -i inventory/mycluster/hosts.yaml --become --become-user=root cluster.yml Nota: Quando o Ansible já estiver instalado por meio de pacotes de sistema no nó de controle, os pacotes Python instalados por meio de sudo pip install -r requirements.txt irão para uma árvore de diretórios diferente (por exemplo, /usr/local/lib/python2.7/dist-packages no Ubuntu) do Ansible (por exemplo, /usr/lib/python2.7/dist-packages/ansible ainda no Ubuntu). Como consequência, o comando ansible-playbook falhará com:
ERROR! no action detected in task. This often indicates a misspelled module name, or incorrect module path.
Isso provavelmente indica que uma tarefa depende de um módulo presente em requirements.txt .
Uma maneira de resolver isso é desinstalar o pacote Ansible do sistema e reinstalar o Ansible via pip , mas isso nem sempre é possível e é preciso tomar cuidado com as versões do pacote. Uma solução alternativa consiste em definir as variáveis de ambiente ANSIBLE_LIBRARY e ANSIBLE_MODULE_UTILS respectivamente para os subdiretórios ansible/modules e ansible/module_utils do local de instalação pip , que é o Location mostrado ao executar pip show [package] antes de executar ansible-playbook .
Uma maneira simples de garantir que você obtenha a versão correta do Ansible é usar a imagem docker pré-construída do Quay. Em seguida, você precisará usar montagens de ligação para acessar o inventário e a chave SSH no contêiner, assim:
git checkout v2.26.0
docker pull quay.io/kubespray/kubespray:v2.26.0
docker run --rm -it --mount type=bind,source="$(pwd)"/inventory/sample,dst=/inventory
--mount type=bind,source="${HOME}"/.ssh/id_rsa,dst=/root/.ssh/id_rsa
quay.io/kubespray/kubespray:v2.26.0 bash
# Inside the container you may now run the kubespray playbooks:
ansible-playbook -i /inventory/inventory.ini --private-key /root/.ssh/id_rsa cluster.yml Veja aqui se você deseja usar este repositório como uma coleção Ansible
Para o Vagrant, precisamos instalar dependências do Python para tarefas de provisionamento. Verifique se Python e pip estão instalados:
python -V && pip -VSe isso retornar a versão do software, você estará pronto. Caso contrário, baixe e instale o Python aqui https://www.python.org/downloads/source/
Instale o Ansible de acordo com o guia de instalação do Ansible e execute a seguinte etapa:
vagrant up Nota: Os tipos de sistema operacional baseados em inicialização Upstart/SysV não são suportados.
ansible_become ou os parâmetros de comando --become or -b devem ser especificados.Hardware: Esses limites são protegidos pelo Kubespray. Os requisitos reais para sua carga de trabalho podem ser diferentes. Para obter um guia de dimensionamento, acesse o guia Construindo grandes clusters.
Você pode escolher entre dez plugins de rede. (padrão: calico , exceto que Vagrant usa flannel )
flanela: rede gre/vxlan (camada 2).
Calico é um provedor de redes e políticas de rede. O Calico oferece suporte a um conjunto flexível de opções de rede projetadas para fornecer a rede mais eficiente em diversas situações, incluindo redes não sobrepostas e sobrepostas, com ou sem BGP. O Calico usa o mesmo mecanismo para impor políticas de rede para hosts, pods e (se estiver usando Istio e Envoy) aplicativos na camada de malha de serviço.
cilium: rede de camada 3/4 (bem como camada 7 para proteger e proteger protocolos de aplicativos), suporta inserção dinâmica de bytecode BPF no kernel Linux para implementar serviços de segurança, rede e lógica de visibilidade.
weave: Weave é uma rede de sobreposição de contêiner leve que não requer um cluster de banco de dados K/V externo. (Consulte a documentação de solução de problemas weave ).
kube-ovn: Kube-OVN integra a virtualização de rede baseada em OVN com Kubernetes. Ele oferece um Container Network Fabric avançado para empresas.
kube-router: Kube-router é um CNI L3 para redes Kubernetes com o objetivo de fornecer simplicidade operacional e alto desempenho: ele usa IPVS para fornecer Kube Services Proxy (se configurado para substituir kube-proxy), iptables para políticas de rede e BGP para ods Rede L3 (opcionalmente com peering BGP com peers BGP fora do cluster). Opcionalmente, ele também pode anunciar rotas para CIDRs de pods de cluster Kubernetes, ClusterIPs, ExternalIPs e LoadBalancerIPs.
macvlan: Macvlan é um driver de rede Linux. Os pods têm seu próprio endereço Mac e IP exclusivo, conectados diretamente à rede física (camada 2).
multus: Multus é um plugin meta CNI que fornece suporte a múltiplas interfaces de rede para pods. Para cada interface, o Multus delega chamadas CNI para plugins CNI secundários, como Calico, macvlan, etc.
custom_cni: você pode especificar alguns manifestos que serão aplicados aos clusters para trazer seu próprio CNI e usar aqueles não suportados pelo Kubespray. Consulte tests/files/custom_cni/README.md e tests/files/custom_cni/values.yaml para obter um exemplo com um CNI fornecido por um Helm Chart.
O plugin de rede a ser usado é definido pela variável kube_network_plugin . Também existe a opção de aproveitar a rede integrada do provedor de nuvem. Consulte também Verificador de rede.
nginx: o controlador de ingresso NGINX.
metallb: o provedor LoadBalancer do serviço bare metal MetalLB.
Testes CI/end-to-end patrocinados por: CNCF, Equinix Metal, OVHcloud, ELASTX.
Consulte a matriz de teste para obter detalhes.
