кубический спрей
v2.26.0
Если у вас есть вопросы, ознакомьтесь с документацией на kubespray.io и присоединяйтесь к нам на канале kubernetes #kubespray . Вы можете получить приглашение здесь
Ниже приведены несколько способов использования Kubespray для развертывания кластера Kubernetes.
Установите Ansible в соответствии с руководством по установке Ansible, затем выполните следующие шаги:
# 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 Примечание. Если Ansible уже установлен через системные пакеты на управляющем узле, пакеты Python, установленные с помощью sudo pip install -r requirements.txt перейдут в другое дерево каталогов (например, /usr/local/lib/python2.7/dist-packages ). в Ubuntu) из Ansible (например, /usr/lib/python2.7/dist-packages/ansible все еще в Ubuntu). Как следствие, команда ansible-playbook завершится ошибкой:
ERROR! no action detected in task. This often indicates a misspelled module name, or incorrect module path.
Вероятно, это указывает на то, что задача зависит от модуля, присутствующего в requirements.txt .
Один из способов решения этой проблемы — удалить системный пакет Ansible, а затем переустановить Ansible через pip , но это не всегда возможно, и нужно позаботиться о версиях пакета. Обходной путь состоит в установке переменных среды ANSIBLE_LIBRARY и ANSIBLE_MODULE_UTILS соответственно в подкаталогах ansible/modules и ansible/module_utils места установки pip , которое является Location отображаемым при запуске pip show [package] перед выполнением ansible-playbook .
Простой способ убедиться, что вы получаете правильную версию Ansible, — использовать предварительно созданный образ Docker от Quay. Затем вам нужно будет использовать привязку для доступа к инвентарю и ключу SSH в контейнере, например:
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 См. здесь, если вы хотите использовать этот репозиторий в качестве коллекции Ansible.
Для Vagrant нам необходимо установить зависимости Python для выполнения задач. Убедитесь, что Python и pip установлены:
python -V && pip -VЕсли это вернет версию программного обеспечения, все готово. Если нет, загрузите и установите Python отсюда https://www.python.org/downloads/source/.
Установите Ansible в соответствии с руководством по установке Ansible, затем выполните следующий шаг:
vagrant up Примечание. Типы ОС на основе инициализации Upstart/SysV не поддерживаются.
ansible_become или параметры команды --become or -b .Аппаратное обеспечение: эти ограничения защищены Kubespray. Фактические требования для вашей рабочей нагрузки могут отличаться. Руководство по выбору размера см. в руководстве «Создание больших кластеров».
Вы можете выбрать один из десяти сетевых плагинов. (по умолчанию: calico , за исключением того, что Vagrant использует flannel )
фланель: сеть gre/vxlan (уровень 2).
Calico — поставщик сетевых политик и сетевых политик. Calico поддерживает гибкий набор сетевых опций, предназначенных для обеспечения наиболее эффективной работы в сети в различных ситуациях, включая сети без наложения и наложения, с BGP или без него. Calico использует тот же механизм для обеспечения соблюдения сетевой политики для хостов, модулей и (при использовании Istio и Envoy) приложений на уровне сервисной сетки.
cilium: сетевой уровень 3/4 (а также уровень 7 для защиты и защиты протоколов приложений), поддерживает динамическую вставку байт-кода BPF в ядро Linux для реализации служб безопасности, логики работы в сети и видимости.
weave: Weave — это облегченная контейнерная оверлейная сеть, для которой не требуется внешний кластер базы данных K/V. (Обратитесь к документации по устранению неполадок weave ).
kube-ovn: Kube-OVN интегрирует виртуализацию сети на основе OVN с Kubernetes. Он предлагает усовершенствованную Container Network Fabric для предприятий.
kube-router: Kube-router — это CNI L3 для сетей Kubernetes, призванный обеспечить простоту эксплуатации и высокую производительность: он использует IPVS для предоставления прокси-сервера Kube Services (если он настроен вместо kube-proxy), iptables для сетевых политик и BGP для ods. Сеть L3 (с возможностью пиринга BGP с узлами BGP вне кластера). Он также может опционально объявлять маршруты к подам кластера Kubernetes CIDR, ClusterIP, externalIP и LoadBalancerIP.
macvlan: Macvlan — это сетевой драйвер Linux. Поды имеют свой собственный уникальный Mac и IP-адрес, подключенные напрямую к физической сети (уровень 2).
multus: Multus — это мета-плагин CNI, который обеспечивает поддержку нескольких сетевых интерфейсов для модулей. Для каждого интерфейса Multus делегирует вызовы CNI вторичным плагинам CNI, таким как Calico, macvlan и т. д.
custom_cni: вы можете указать некоторые манифесты, которые будут применяться к кластерам, чтобы предоставить вам собственный CNI и использовать неподдерживаемые Kubespray. См. tests/files/custom_cni/README.md tests/files/custom_cni/values.yaml для примера с CNI, предоставленным диаграммой Helm.
Используемый сетевой плагин определяется переменной kube_network_plugin . Вместо этого существует также возможность использовать встроенную сеть облачного провайдера. См. также Проверка сети.
nginx: входной контроллер NGINX.
metallb: поставщик службы LoadBalancer без операционной системы MetalLB.
CI/сквозные тесты, спонсируемые: CNCF, Equinix Metal, OVHcloud, ELASTX.
Подробности смотрите в тестовой матрице.
