cilium-kubernetes

Эта Ansible роль устанавливает сеть Cilium на кластер Kubernetes. В основном она использует официальный Helm chart. В данный момент поддерживаются процессы установки, обновления и удаления развертывания Cilium.

Версии

Я помечаю каждый релиз и стараюсь следовать семантическому версионированию. Если вы хотите использовать эту роль, я рекомендую проверить последнюю метку. Основная ветка — это, по сути, разработка, в то время как метки обозначают стабильные релизы. Метка 13.0.0+1.15.3 означает, что это релиз 13.0.0 этой роли и он содержит версию Cilium chart 1.15.3. Если сама роль изменится, число X.Y.Z перед + увеличится. Если изменится версия Cilium chart, число X.Y.Z после + тоже увеличится. Это позволяет помечать исправления ошибок и новые основные версии роли, пока она всё ещё разрабатывается для конкретного релиза Cilium.

Требования

Необходимо иметь установленный бинарник Helm 3 на хосте, где выполняется ansible-playbook, или на том хосте, куда вы делегировали сценарии (например, с использованием переменной cilium_delegate_to). Вы можете:

• использовать менеджер пакетов по вашему выбору, если ваша дистрибуция включает helm в репозиториях (например, для Archlinux используйте sudo pacman -S helm)
• или использовать одну из Ansible ролей Helm (например, helm, которая будет также установлена, если вы используете ansible-galaxy role install -vr requirements.yml)
• или загрузить бинарник напрямую с релизов Helm и положить его в директорию /usr/local/bin/.

Также требуется правильно настроенный KUBECONFIG (по умолчанию он находится по пути ${HOME}/.kube/config). Обычно, если kubectl работает с вашим кластером, то с этим всё в порядке.

Кроме того, необходимо установить коллекцию Ansible kubernetes.core. Это можно сделать, используя файл collections.yml, включенный в эту роль: ansible-galaxy install -r collections.yml.

И, конечно, вам нужен кластер Kubernetes ;-)

Установка

• Загрузите напрямую с Github (перейдите в директорию Ansible ролей перед клонированием. Вы можете найти путь к роли, используя команду ansible-config dump | grep DEFAULT_ROLES_PATH): git clone https://github.com/githubixx/ansible-role-cilium-kubernetes.git githubixx.cilium_kubernetes

• Через команду ansible-galaxy и загрузите напрямую из Ansible Galaxy: ansible-galaxy install role githubixx.cilium_kubernetes

• Создайте файл requirements.yml со следующим содержимым (это загрузит роль из Github) и установите с помощью ansible-galaxy role install -r requirements.yml (при необходимости измените version):

---
roles:
  - name: githubixx.cilium_kubernetes
    src: https://github.com/githubixx/ansible-role-cilium-kubernetes.git
    version: 13.0.0+1.15.3

Журнал изменений

История изменений:

Смотрите полный CHANGELOG.md

Недавние изменения:

13.0.0+1.15.3

Ломающее изменения

• изменения в templates/cilium_values_default.yml.j2:
  • добавлены kubeProxyReplacement, nodePort и socketLB (это необходимо, так как BPF masquerade требует NodePort)

Обновление

• обновление до Cilium v1.15.3

Molecule

• заменены Vagrant generic/ubuntu2204 образами alvistack/ubuntu-22.04

12.0.0+1.15.0

• обновление до Cilium v1.15.0
• рефакторинг настройки Molecule
• введена переменная cilium_chart_values_directory

Переменные роли

# версия Helm chart
cilium_chart_version: "1.15.3"

# имя Helm chart
cilium_chart_name: "cilium"

# URL Helm chart
cilium_chart_url: "https://helm.cilium.io/"

# пространство имен Kubernetes, в котором должны быть установлены ресурсы Cilium
cilium_namespace: "cilium"

# Директория, содержащая файл значений Helm chart. Ansible будет пытаться найти
# файл с именем "values.yml.j2" или "values.yaml.j2" в указанной директории
# (".j2" означает, что вы можете использовать обычные шаблоны Jinja2).
# Если файл не найден, будет использован файл "templates/cilium_values_default.yml.j2"
# (который, кстати, можно использовать в качестве шаблона). Содержимое этого файла
# будет передано команде "helm install/template" в качестве файла значений.
cilium_chart_values_directory: "/tmp/cilium/helm"

# настройки etcd. Если переменная "cilium_etcd_enabled" определена и установлена в "true",
# настройки Cilium etcd будут сгенерированы и развернуты. В противном случае все последующие
# настройки "cilium_etcd_*" будут игнорироваться.
#
cilium_etcd_enabled: "true"

# Интерфейс, на котором слушают демоны etcd. Если демоны etcd связаны с
# интерфейсом WireGuard, это значение должно быть "wg0" (по умолчанию) например.
# Вы также можете использовать переменную вроде "{{ etcd_interface }}", если вы использовали
# мою роль etcd (https://github.com/githubixx/ansible-role-etcd)
cilium_etcd_interface: "eth0"

# Порт, на котором слушают демоны etcd
cilium_etcd_client_port: 2379

# Группа хостов etcd в файле "hosts" Ansible. Это значение используется в
# шаблоне "templates/cilium_values_default.yml.j2" для определения IP
# адресов хостов, на которых слушают демоны etcd.
cilium_etcd_nodes_group: "k8s_etcd"

# Если эта переменная определена, будет установлен секрет Kubernetes, который
# содержит файлы сертификатов, указанные в "cilium_etcd_cafile",
# "cilium_etcd_certfile" и "cilium_etcd_keyfile".
#
# Это приведет к установлению безопасного соединения (https) с etcd.
# Это, конечно, требует, чтобы etcd был настроен для использования SSL/TLS.
#
# Если это значение не определено (например, закомментировано), остальные
# настройки "cilium_etcd_*" ниже игнорируются, и соединение с etcd будет установлено
# небезопасно через "http".
cilium_etcd_secrets_name: "cilium-etcd-secrets"

# Где найти файлы сертификатов, указанные ниже. Если вы использовали мою
# роль для сертификатов Kubernetes (https://github.com/githubixx/ansible-role-kubernetes-ca)
# вы можете уже иметь определенную переменную "k8s_ca_conf_directory", которую вы
# можете повторно использовать здесь. Эта роль также генерирует файлы сертификатов, которые могут
# быть использованы для следующих переменных.
# По умолчанию это будет "$HOME/k8s/certs" текущего пользователя, который выполняет
# команду "ansible-playbook".
cilium_etcd_cert_directory: "{{ '~/k8s/certs' | expanduser }}"

# файл удостоверяющего органа сертификата etcd (файл будет загружен в "cilium_etcd_cert_directory")
cilium_etcd_cafile: "ca-etcd.pem"

# файл сертификата etcd (файл будет загружен в "cilium_etcd_cert_directory")
# Убедитесь, что сертификат содержит IP-адреса в "Subject
# Alternative Name" (SAN) интерфейсов, на которых слушат демоны etcd
# (это IP-адреса интерфейсов, указанных в "cilium_etcd_interface").
# Это уже обрабатывается моей ролью для сертификатов Kubernetes
# (https://github.com/githubixx/ansible-role-kubernetes-ca), если вы её использовали.
cilium_etcd_certfile: "cert-cilium.pem"

# файл ключа сертификата etcd (файл будет загружен в "cilium_etcd_cert_directory")
cilium_etcd_keyfile: "cert-cilium-key.pem"

# По умолчанию все задачи, которые требуют связи с Kubernetes
# кластером, выполняются на вашем локальном хосте (127.0.0.1). Но если у него
# нет прямого соединения с этим кластером или они должны выполняться
# в другом месте, эту переменную можно изменить соответственно.
cilium_delegate_to: 127.0.0.1

# Показывает "helm" команду, которая была выполнена, если задача использует Helm для
# установки, обновления или удаления такого ресурса.
cilium_helm_show_commands: false

# Без переменной "cilium_action" эта роль просто отрендерит файл
# со всеми ресурсами, которые будут установлены или обновлены. Сгенерированный
# файл с ресурсами будет называться "template.yml" и будет помещен в
# указанную ниже директорию.
cilium_template_output_directory: "{{ '~/cilium/template' | expanduser }}"

Использование

Первое, что нужно сделать, это проверить templates/cilium_values_default.yml.j2. Этот файл содержит значения/настройки для Helm chart Cilium, отличающиеся от значений по умолчанию, которые находятся здесь. Значения по умолчанию для этой Ansible роли используют кластер etcd с поддержкой TLS. Если у вас самоподдерживаемый/наземный кластер Kubernetes, с большой вероятностью уже запущен кластер etcd для API сервера Kubernetes, как это происходит у меня. Я использую свою роль Ansible etcd для установки такого кластера etcd и свою роль Kubernetes Certificate Authority для генерации сертификатов. Поэтому, если вы использовали мои роли, вы можете использовать эту роль Cilium в основном как есть.

Шаблон templates/cilium_values_default.yml.j2 также содержит некоторые if-условия для использования кластера etcd, который не поддерживает TLS. Смотрите defaults/main.yml, чтобы проверить, какие значения можно изменить. Вы также можете ввести свои переменные. Чтобы использовать свои значения, просто создайте файл с именем values.yml.j2 или values.yaml.j2 и поместите его в директорию, указанную в cilium_chart_values_directory. Затем эта роль будет использовать этот файл для рендеринга значений Helm.

После того как файл значений будет на месте и значения из defaults/main.yml будут проверены, роль можно установить. Большинство задач роли по умолчанию выполняются локально, так как довольно много задач требует связи с сервером API Kubernetes или выполнения команд Helm. Но вы можете делегировать такого рода задачи на другой хост, используя переменную cilium_delegate_to (см. выше). Убедитесь, что хост, которому вы делегируете такого рода задачи, имеет соединение с сервером API Kubernetes, и у пользователя есть действительный файл KUBECONFIG.

По умолчанию действие заключается в том, чтобы просто отрендерить YAML-файл ресурсов Kubernetes после замены всех переменных Jinja2 и т. д. В разделе Пример сценария ниже есть Пример 2 (присвоить тег роли). Роли githubixx.cilium_kubernetes присвоен тег role-cilium-kubernetes. Предполагая, что значения для Helm chart должны быть отрендерены (в этом случае ничего не будет установлено), и сценарий называется k8s.yml, выполните следующую команду:

ansible-playbook --tags=role-cilium-kubernetes k8s.yml

Чтобы отрендерить шаблон в другую директорию, используйте переменную cilium_template_output_directory, например:

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_template_output_directory="/tmp/cilium" k8s.yml

Если вы хотите видеть команды helm и параметры, которые были выполнены в журналах, вы также можете указать --extra-vars cilium_helm_show_commands=true.

Одна из финальных задач называется TASK [githubixx.cilium_kubernetes : Записать шаблоны в файл]. Эта задача рендерит шаблон с ресурсами, которые будут созданы, в директорию, указанную в cilium_template_output_directory. Файл будет называться template.yml. Директория/файл будут помещены на вашем локальном компьютере, чтобы вы могли их просмотреть.

Если отрендеренный вывод содержит всё, что вам нужно, роль можно установить, что в конечном итоге развернёт Cilium:

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_action=install k8s.yml

Чтобы проверить, всё ли развернуто, используйте обычные команды kubectl, например kubectl -n <cilium_namespace> get pods -o wide.

Так как Cilium выпускает обновления каждые несколько недель/месяцев, роль также может выполнять обновления. Роль, по сути, выполняет описанное в руководстве по обновлению Cilium. Это означает, что будет установлен предварительный контроль Cilium, и выполнены некоторые проверки перед фактическим обновлением. Ознакомьтесь с tasks/upgrade.yml, чтобы увидеть, что происходит до, во время и после обновления. Конечно, вам следует ознакомиться с руководством по обновлению Cilium в целом, чтобы проверить основные изменения и подобные моменты перед обновлением. Также убедитесь, что вы ознакомились с Примечаниями по обновлению!

Если обновление прошло неудачно, можно в основном инициировать Откат до предыдущей версии, просто изменив переменную cilium_chart_version. Но вам стоит прочитать руководство по откату. Переключение между минорными релизами обычно не представляет проблемы, но переход от одной основной версии к предыдущей может быть не таким простым.

Также проверьте файл templates/cilium_values_default_pre_flight_check.yml.j2. Если вам нужно настроить значения для предварительной проверки, вы можете либо изменить этот файл, либо создать файл templates/cilium_values_user_pre_flight_check.yml.j2 с вашими собственными значениями.

Перед выполнением обновления вам в основном нужно только изменить переменную cilium_chart_version, например, с 1.13.4 на 1.14.5, чтобы обновиться с 1.13.4 до 1.14.5. Чтобы выполнить обновление, выполните:

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_action=upgrade k8s.yml

Как уже упоминалось, роль уже включает несколько проверок, чтобы убедиться, что обновление проходит гладко, но вам также следует снова проверить с помощью kubectl, все ли работает так, как ожидалось, после обновления.

И наконец, если вы хотите удалить Cilium, вы можете снова удалить все ресурсы:

ansible-playbook --tags=role-cilium-kubernetes --extra-vars cilium_action=delete k8s.yml

Если у вас не настроены какие-либо плагины CNI, это приведет к тому, что процесс kubelet на рабочих узлах Kubernetes будет периодически выдавать ошибки CNI, так как CNI больше нет, и, конечно, связь между подами на разных хостах будет отсутствовать вместе с любыми сетевыми политиками и подобным.

Пример сценария

Пример 1 (без тега роли):

- hosts: k8s_worker
  roles:
    - githubixx.cilium_kubernetes

Пример 2 (присвоить тег роли):

-
  hosts: k8s_worker
  roles:
    -
      role: githubixx.cilium_kubernetes
      tags: role-cilium-kubernetes

Тестирование

Эта роль имеет небольшую тестовую настройку, которая создается с помощью Molecule, libvirt (vagrant-libvirt) и QEMU/KVM. Пожалуйста, смотрите мой блог Тестирование ролей Ansible с Molecule, libvirt (vagrant-libvirt) и QEMU/KVM, чтобы узнать, как настроить. Конфигурация теста здесь.

После этого можно выполнить molecule. Следующая команда выполнит базовую настройку и создаст шаблон ресурсов (дефолтное действие, см. выше), которые будут созданы:

molecule converge

Установка Cilium и необходимых ресурсов. Это настроит несколько виртуальных машин (VM) и установит кластер Kubernetes. Эта настройка будет использоваться для установки Cilium с помощью этой роли.

molecule converge -- --extra-vars cilium_action=install

Следующая команда может быть использована для установки CoreDNS для DNS в Kubernetes и ограничения узлов контроллеров для запуска только подов Cilium:

molecule converge -- --extra-vars cilium_setup_networking=install

Обновление Cilium или изменение параметров:

molecule converge -- --extra-vars cilium_action=upgrade

Удаление Cilium и его ресурсов:

molecule converge -- --extra-vars cilium_action=delete

Чтобы провести несколько тестов, используйте (при желании добавьте -v для более подробного вывода):

molecule verify

Для очистки выполните:

molecule destroy

Лицензия

GNU GENERAL PUBLIC LICENSE версия 3

Информация об авторе

http://www.tauceti.blog