cilium-kubernetes

这个 Ansible 角色在 Kubernetes 集群上安装 Cilium 网络。它使用官方的 Helm chart。目前支持安装、升级和删除 Cilium 部署等操作。

版本

我为每次发布打标签并尽量遵循 语义版本控制。如果您想使用此角色，建议您查看最新的标签。主分支主要用于开发，而标签标记了稳定的发布版本。标签 13.0.0+1.15.3 表示这是该角色的第 13.0.0 版本，包含 Cilium chart 版本 1.15.3。如果角色本身发生变化，X.Y.Z 中 + 前的版本号会增加；如果 Cilium chart 版本变化，+ 后的版本号也会增加。这使得可以在为特定 Cilium 版本开发时标记修复和新的主要版本。

要求

您需要在执行 ansible-playbook 的主机上安装 Helm 3 或在您委托播放本的主机上（例如，通过使用 cilium_delegate_to 变量）。您可以选择：

• 如果您的发行版在其仓库中包括 helm，可以使用您喜欢的包管理器（例如，Archlinux 使用 sudo pacman -S helm）。
• 或者使用 Ansible 的其中一个 Helm 角色（例如 helm - 如果您使用 ansible-galaxy role install -vr requirements.yml 也会安装该角色）。
• 或直接从 Helm releases 下载二进制文件，并放置到 /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 伪装需要 NodePort）

更新

• 升级到 Cilium v1.15.3

Molecule

• 用 alvistack/ubuntu-22.04 替换 Vagrant generic/ubuntu2204 盒子

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"

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

# Cilium 资源应该安装的 Kubernetes 命名空间
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 角色（https://github.com/githubixx/ansible-role-etcd），
# 也可以使用变量 "{{ etcd_interface }}"
cilium_etcd_interface: "eth0"

# etcd 守护进程监听的端口
cilium_etcd_client_port: 2379

# Ansible etcd 主机组在 Ansible 的 "hosts" 文件中使用。这个值用于
# "templates/cilium_values_default.yml.j2" 模板，以确定 etcd
# 守护进程监听的主机的 IP 地址。
cilium_etcd_nodes_group: "k8s_etcd"

# 如果定义了此变量，则将安装一个 Kubernetes 秘密，包含在
# "cilium_etcd_cafile"、"cilium_etcd_certfile" 和 "cilium_etcd_keyfile" 中定义的证书文件
#
# 这会导致与 etcd 建立安全连接（https）。
# 当然，这要求 etcd 配置为使用 SSL/TLS。
#
# 如果此值未定义（例如，被注释掉），以下的 "cilium_etcd_*"
# 设置将被忽略，与 etcd 的连接将通过 "http"
# 非安全地建立。
cilium_etcd_secrets_name: "cilium-etcd-secrets"

# 找到以下定义的证书文件的位置。如果您使用了我的
# Kubernetes Certificate Authority 角色（https://github.com/githubixx/ansible-role-kubernetes-ca）
# 您可能已经定义了 "k8s_ca_conf_directory" 变量，可以在这里重用。
# 此角色也生成可用于以下变量的证书文件。
# 默认情况下，这将在运行 "ansible-playbook" 命令的当前用户的 "$HOME/k8s/certs"。
cilium_etcd_cert_directory: "{{ '~/k8s/certs' | expanduser }}"

# etcd 证书授权文件（文件将在 "cilium_etcd_cert_directory" 中提取）
cilium_etcd_cafile: "ca-etcd.pem"

# etcd 证书文件（文件将在 "cilium_etcd_cert_directory" 中提取）
# 确保证书在监听 etcd 守护进程的接口上包含 IP 地址
# （这就是在 "cilium_etcd_interface" 中定义的接口的 IP 地址）。
# 如果您使用了我的 Kubernetes Certificate Authority 角色
# （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。该文件包含与默认值不同的 Cilium Helm chart 的值/设置，这些默认值位于 这里。此 Ansible 角色的默认值使用了启用 TLS 的 etcd 集群。如果您有一个自托管/裸金属的 Kubernetes 集群，您很可能已经有一个运行的 etcd 集群来为 Kubernetes API 服务器服务，这种情况对我来说也是如此。我使用我的 Ansible etcd 角色 来安装这样的 etcd 集群，以及我的 Kubernetes Certificate Authority 角色 来生成证书。因此，如果您使用了我的角色，可以直接使用此 Cilium 角色。

templates/cilium_values_default.yml.j2 模板中还包含了一些 if 子句，以便使用未启用 TLS 的 etcd 集群。查看 defaults/main.yml 以检查哪些值可以更改。您还可以引入自己的变量。要使用自己的值，只需创建一个名为 values.yml.j2 或 values.yaml.j2 的文件，并将其放入 cilium_chart_values_directory 中指定的目录中。然后，此角色将使用该文件来渲染 Helm 值。

在值文件到位并检查了 defaults/main.yml 中的值后，可以安装该角色。大部分角色的任务默认在本地执行，因为许多任务需要与 Kubernetes API 服务器通信或执行 Helm 命令。但是，您可以使用 cilium_delegate_to 变量将此类任务委托给其他主机（如上所述）。只需确保您委托这些任务的主机能够连接到 Kubernetes API 服务器，并且用户具有有效的 KUBECONFIG 文件。

默认操作是在替换所有 Jinja2 变量后的情况下，仅渲染 Kubernetes 资源的 YAML 文件。以下是 示例剧本 部分中的 示例 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。

其中一个最终任务是 任务 [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 变量基本上启动 回滚 到先前版本。但您肯定要阅读 Cilium 的 回滚指南。在较小版本之间切换通常没有问题，但从一个主要版本切换到另一个之前的版本可能就不那么简单。

也要检查 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 插件，这将导致 Kubernetes 工作节点上的 kubelet 进程时不时出现 CNI 错误，因为不再有与 CNI 相关的内容，并且显然不同主机之间 Pods 之间的连接也会消失，连同任何网络策略等。

示例剧本

示例 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 创建。请查看我的博客帖子 使用 Molecule、libvirt (vagrant-libvirt) 和 QEMU/KVM 测试 Ansible 角色 了解如何设置。测试配置 在这里。

之后可以执行 molecule。以下命令将进行基本设置并创建将要创建的资源的模板（默认操作见上文）：

molecule converge

安装 Cilium 和所需的资源。这将设置几个虚拟机 (VM) 并安装一个 Kubernetes 集群。该设置将用于通过此角色安装 Cilium。

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

以下命令可用于安装 CoreDNS 以处理 Kubernetes DNS 相关的任务，并使控制节点仅运行 Cilium pods：

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 通用公共许可证 第 3 版

作者信息

http://www.tauceti.blog