尧图网站建设 
在 AWS 上使用 Kops 部署 Kubernetes 集群并接入 Cilium CNI 完整指南【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本指南基于 Cilium 官方安装文档完整演示如何在 AWS 上使用 Kops 创建 Kubernetes 集群并以 Cilium 作为 CNIContainer Network Interface插件接入其中。读者将掌握 kops 的安装与 IAM/S3 环境准备、一条命令创建启用 Cilium 的集群、安装并验证 Cilium 组件、以及清理集群的完整流程同时理解--networking cilium背后 kops 所提供的丰富 Cilium 集成能力kube-proxy-free、IPAM ENI、专用 etcd 等。Kops 与 Cilium 的集成方式KopsKubernetes Operations是 Kubernetes 官方社区维护的生产级集群部署工具能够自动化完成 AWS 上包括 AutoScaling、Volumes、VPC 等在内的大量部署基础设施。自 kops 1.9 版本起Cilium 可以作为 kops 部署集群的 CNI 插件被直接接入。kops 为 Cilium 提供了多种开箱即用的配置形态本指南只演示最基础的一种kube-proxy-free以 Cilium 的 eBPF 能力完全取代 kube-proxy见 Kubernetes Without kube-proxyIPAM ENI在 AWS 上使用 ENI弹性网络接口作为 Cilium 的 IP 地址管理后端见 IPAM ENI 文档专用 etcd 集群为 Cilium 部署独立的 etcd 集群作为键值存储而非使用 Kubernetes CRD。前置条件开始之前你需要准备以下工具与账号权限aws cliAWS 命令行工具kubectlKubernetes 命令行工具AWS 账号且具有以下 IAM 策略权限AmazonEC2FullAccessAmazonRoute53FullAccessAmazonS3FullAccessIAMFullAccessAmazonVPCFullAccess这些权限覆盖了 kops 在 AWS 上创建 VPC、EC2 实例、负载均衡、S3 状态存储、DNS 记录以及 IAM 角色所需的最小操作面。安装 kops根据操作系统选择对应的安装方式Linuxcurl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d -f 4)/kops-linux-amd64 chmod x kops-linux-amd64 sudo mv kops-linux-amd64 /usr/local/bin/kopsMacOSbrew update brew install kops安装完成后可通过kops version验证命令是否可用。设置 IAM 组与用户kops 需要一个专用的 IAM 用户来操作 AWS 资源。在已具备上述前置权限的前提下按如下步骤创建名为kops的 IAM 组与用户$ # 创建名为 kops 的 IAM 组并授予权限 $ aws iam create-group --group-name kops $ aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonEC2FullAccess --group-name kops $ aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonRoute53FullAccess --group-name kops $ aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess --group-name kops $ aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/IAMFullAccess --group-name kops $ aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonVPCFullAccess --group-name kops $ aws iam create-user --user-name kops $ aws iam add-user-to-group --user-name kops --group-name kops $ aws iam create-access-key --user-name kops最后一条命令会输出该用户的AccessKeyId与SecretAccessKey请妥善保存并通过aws configure配置到本地环境。创建 S3 状态存储桶kops 依赖一个专用的 S3 存储桶来保存集群的状态与表示state and representation。桶名需要全局唯一建议使用 FQDN 的倒写形式并附加集群的简短描述作为前缀同时务必选择你计划部署集群的 Region$ aws s3api create-bucket --bucket prefix-example-com-state-store --region us-west-2 --create-bucket-configuration LocationConstraintus-west-2 $ export KOPS_STATE_STOREs3://prefix-example-com-state-store提示--create-bucket-configuration LocationConstraintus-west-2在非 us-east-1 区域创建桶时为必填项。完成上述步骤后即可获得一个可用的集群创建环境。更详尽的 kops 安装与 AWS 配置说明可参考 kops 官方 AWS 安装文档。Cilium 前置条件在创建集群前还需要确认 Cilium 的系统级要求是否满足尤其是Linux 内核版本与键值存储key-value store版本详见 Cilium 的 系统要求文档。以当前仓库版本为例Cilium 要求Linux 内核≥ 5.10或等价版本例如 RHEL 8.10 上的 4.18键值存储etcd≥ 3.1.0。同时内核需要启用以下关键配置项发行版默认内核通常已开启CONFIG_BPFy CONFIG_BPF_EVENTSy CONFIG_BPF_SYSCALLy本指南使用的 kops 默认 AMI 已经满足 Cilium 所需的最低内核版本要求因此无需额外替换镜像。创建集群创建集群前有两个关键决策点可用区zones必须通过--master-zones和--zones分别指定 master 与 worker 节点所在可用区。master 可用区数量应为**奇数1、3…**以保证高可用为简化演示本指南将 master 与 worker 都放在同一组 3 个可用区内。gossip 协议集群为免去预先创建托管 DNS Zone 的步骤本指南使用基于 gossip 的集群。gossip 模式下集群名NAME必须以k8s.local结尾若同一个 kops 用户管理多个集群建议在名称前加上com-company-emailid-之类的前缀以保证唯一。$ export NAMEcom-company-emailid-cilium.k8s.local $ kops create cluster --state${KOPS_STATE_STORE} --node-count 3 --topology private --master-zones us-west-2a,us-west-2b,us-west-2c --zones us-west-2a,us-west-2b,us-west-2c --networking cilium --cloud-labels TeamDev,OwnerAdmin ${NAME} --yes执行过程中 kops 可能会提示你创建 SSH 公/私钥对$ ssh-keygen集群创建命令各 flag 详解Flag含义--state${KOPS_STATE_STORE}指定 kops 存储集群状态与表示的 S3 存储桶即前面创建的s3://prefix-example-com-state-store--node-count 3Kubernetes 集群中的 worker 节点数量--topology private使用私有拓扑创建集群即所有 master/node 都部署在 VPC 内的私有子网中--master-zones us-west-2a,us-west-2b,us-west-2c指定 3 个 master 节点所在的可用区分布于不同可用区以实现 HA--zones us-west-2a,us-west-2b,us-west-2cworker 节点部署所在的可用区--networking cilium指定 Cilium 作为网络 CNI 插件也可以使用cilium-etcd后者会为键值存储使用一套独立的 etcd 集群而非 CRD--cloud-labels TeamDev,OwnerAdmin应用到集群实例上的云标签${NAME}集群名称必须以k8s.local结尾以启用 gossip 集群关于--networking的补充cilium与cilium-etcd两种模式的核心区别在于 Cilium 状态的键值存储后端。默认的cilium模式将状态保存在 Kubernetes CRD 中无需额外运维 etcdcilium-etcd模式则为 Cilium 部署一套专用的 etcd 集群适用于对多集群共享状态或既有 etcd 生态有要求的场景。验证安装集群创建完成后通过以下两种方式之一验证 Cilium 是否正确安装并运行。方式一使用 Cilium CLI先安装最新版本的 Cilium CLI可用于安装 Cilium、检查安装状态以及启用/关闭 clustermesh、Hubble 等功能LinuxCILIUM_CLI_VERSION$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt) CLI_ARCHamd64 if [ $(uname -m) aarch64 ]; then CLI_ARCHarm64; fi curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum} sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin rm cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}macOSCILIUM_CLI_VERSION$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt) CLI_ARCHamd64 if [ $(uname -m) arm64 ]; then CLI_ARCHarm64; fi curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-darwin-${CLI_ARCH}.tar.gz{,.sha256sum} shasum -a 256 -c cilium-darwin-${CLI_ARCH}.tar.gz.sha256sum sudo tar xzvfC cilium-darwin-${CLI_ARCH}.tar.gz /usr/local/bin rm cilium-darwin-${CLI_ARCH}.tar.gz{,.sha256sum}随后运行状态检查命令验证 Cilium 是否已正确安装$ cilium status --wait /¯¯\ /¯¯\__/¯¯\ Cilium: OK \__/¯¯\__/ Operator: OK /¯¯\__/¯¯\ Hubble: disabled \__/¯¯\__/ ClusterMesh: disabled \__/ DaemonSet cilium Desired: 2, Ready: 2/2, Available: 2/2 Deployment cilium-operator Desired: 2, Ready: 2/2, Available: 2/2 Containers: cilium-operator Running: 2 cilium Running: 2 Image versions cilium quay.io/cilium/cilium:v1.9.5: 2 cilium-operator quay.io/cilium/operator-generic:v1.9.5: 2输出中Cilium: OK与Operator: OK表示核心组件健康DaemonSet cilium与Deployment cilium-operator的 Desired/Ready 数量一致即说明所有节点上的 agent 均已就绪。最后运行连通性测试验证集群网络是否正常工作$ cilium connectivity test ℹ️ Monitor aggregation detected, will skip some flow validation steps ✨ [k8s-cluster] Creating namespace for connectivity check... (...) --------------------------------------------------------------------------------------------------------------------- Test Report --------------------------------------------------------------------------------------------------------------------- ✅ 69/69 tests successful (0 warnings)注意连通性测试可能因某个 Pod 内打开文件过多而部署失败。若遇到此类报错可提高宿主机上的inotify资源限制后重试。方式二手动验证kubectl通过 kubectl 监控 Cilium 及相关组件在 kube-system 命名空间中的部署过程$ kubectl -n kube-system get pods --watch NAME READY STATUS RESTARTS AGE cilium-operator-cb4578bc5-q52qk 0/1 Pending 0 8s cilium-s8w5m 0/1 PodInitializing 0 7s coredns-86c58d9df4-4g7dd 0/1 ContainerCreating 0 8m57s coredns-86c58d9df4-4l6b2 0/1 ContainerCreating 0 8m57s所有组件可能需要几分钟才能完成启动最终状态应全部变为 Runningcilium-operator-cb4578bc5-q52qk 1/1 Running 0 4m13s cilium-s8w5m 1/1 Running 0 4m12s coredns-86c58d9df4-4g7dd 1/1 Running 0 13m coredns-86c58d9df4-4l6b2 1/1 Running 0 13m接下来部署连通性检查应用验证 Pod 之间的网络连通性。建议创建独立的命名空间kubectl create ns cilium-test部署检查清单kubectl apply -n cilium-test -f examples/kubernetes/connectivity-check/connectivity-check.yaml该清单位于 examples/kubernetes/connectivity-check/connectivity-check.yaml会部署一系列 Deployment通过多种连通性路径互相访问包括带/不带 Service 负载均衡以及各种网络策略组合。Pod 名称标明其连通性变体readiness 与 liveness 探针则标示测试成败$ kubectl get pods -n cilium-test NAME READY STATUS RESTARTS AGE echo-a-76c5d9bd76-q8d99 1/1 Running 0 66s echo-b-795c4b4f76-9wrrx 1/1 Running 0 66s echo-b-host-6b7fc94b7c-xtsff 1/1 Running 0 66s host-to-b-multi-node-clusterip-85476cd779-bpg4b 1/1 Running 0 66s host-to-b-multi-node-headless-dc6c44cb5-8jdz8 1/1 Running 0 66s pod-to-a-79546bc469-rl2qq 1/1 Running 0 66s pod-to-a-allowed-cnp-58b7f7fb8f-lkq7p 1/1 Running 0 66s pod-to-a-denied-cnp-6967cb6f7f-7h9fn 1/1 Running 0 66s pod-to-b-intra-node-nodeport-9b487cf89-6ptrt 1/1 Running 0 65s pod-to-b-multi-node-clusterip-7db5dfdcf7-jkjpw 1/1 Running 0 66s pod-to-b-multi-node-headless-7d44b85d69-mtscc 1/1 Running 0 66s pod-to-b-multi-node-nodeport-7ffc76db7c-rrw82 1/1 Running 0 65s pod-to-external-1111-d56f47579-d79dz 1/1 Running 0 66s pod-to-external-fqdn-allow-google-cnp-78986f4bcf-btjn7 1/1 Running 0 66s提示如果是在单节点集群上部署检查**多节点multi-node**功能的 Pod 会一直处于Pending状态。这是预期行为——这些 Pod 至少需要 2 个节点才能被成功调度。验证完成后删除测试命名空间kubectl delete ns cilium-test删除集群当不再需要集群时使用 kops 删除集群并撤销其在 AWS 上创建的全部依赖资源AutoScaling、VPC、卷等。--yes参数表示立即执行销毁而不进入确认流程$ kops delete cluster ${NAME} --yes深入kops 中 Cilium 的高级配置形态本指南仅覆盖了最基础的--networking cilium配置。kops 官方在 Cilium 网络集成上还提供了更多开箱即用的选项值得在生产环境中按需启用kube-proxy-free无 kube-proxy 模式kops 可以创建完全不含 kube-proxy 的集群由 Cilium 基于 eBPF 的 socket-LB 特性全权接管 Service 负载均衡、ClusterIP/NodePort/LoadBalancer 处理与南北向流量转发。其原理与手动配置方法详见 Kubernetes Without kube-proxy。IPAM ENI在 AWS 环境下让 Cilium 直接使用 VPC ENI 分配 Pod IP每 Pod 一个 ENI 辅助 IP与 VPC 路由表原生集成规避隧道或叠加网络的额外开销详见 IPAM ENI 文档。cilium-etcd 后端如创建集群时将--networking指定为cilium-etcdkops 会为 Cilium 部署专用 etcd 集群作为键值存储代替默认的 CRD 存储方式。进一步阅读kops 官方网络文档提供了 Cilium 在 kops 中更多配置选项的说明kops 的CiliumNetworkingSpec结构定义给出了 kops 侧所有可调参数的完整清单包括上述高级模式的开关字段。若需要从底层理解 Cilium 在节点上的运行形态可继续阅读 系统要求内核与依赖版本、Cilium Operator 内部机制以及仓库内 Cilium agent 与 Operator 的实际实现daemon/、operator/。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 在 AWS 上使用 Kops 部署 Kubernetes 集群并接入 Cilium CNI 完整指南
在 AWS 上使用 Kops 部署 Kubernetes 集群并接入 Cilium CNI 完整指南【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本指南基于 Cilium 官方安装文档完整演示如何在 AWS 上使用 Kops 创建 Kubernetes 集群并以 Cilium 作为 CNIContainer Network Interface插件接入其中。读者将掌握 kops 的安装与 IAM/S3 环境准备、一条命令创建启用 Cilium 的集群、安装并验证 Cilium 组件、以及清理集群的完整流程同时理解--networking cilium背后 kops 所提供的丰富 Cilium 集成能力kube-proxy-free、IPAM ENI、专用 etcd 等。Kops 与 Cilium 的集成方式KopsKubernetes Operations是 Kubernetes 官方社区维护的生产级集群部署工具能够自动化完成 AWS 上包括 AutoScaling、Volumes、VPC 等在内的大量部署基础设施。自 kops 1.9 版本起Cilium 可以作为 kops 部署集群的 CNI 插件被直接接入。kops 为 Cilium 提供了多种开箱即用的配置形态本指南只演示最基础的一种kube-proxy-free以 Cilium 的 eBPF 能力完全取代 kube-proxy见 Kubernetes Without kube-proxyIPAM ENI在 AWS 上使用 ENI弹性网络接口作为 Cilium 的 IP 地址管理后端见 IPAM ENI 文档专用 etcd 集群为 Cilium 部署独立的 etcd 集群作为键值存储而非使用 Kubernetes CRD。前置条件开始之前你需要准备以下工具与账号权限aws cliAWS 命令行工具kubectlKubernetes 命令行工具AWS 账号且具有以下 IAM 策略权限AmazonEC2FullAccessAmazonRoute53FullAccessAmazonS3FullAccessIAMFullAccessAmazonVPCFullAccess这些权限覆盖了 kops 在 AWS 上创建 VPC、EC2 实例、负载均衡、S3 状态存储、DNS 记录以及 IAM 角色所需的最小操作面。安装 kops根据操作系统选择对应的安装方式Linuxcurl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d -f 4)/kops-linux-amd64 chmod x kops-linux-amd64 sudo mv kops-linux-amd64 /usr/local/bin/kopsMacOSbrew update brew install kops安装完成后可通过kops version验证命令是否可用。设置 IAM 组与用户kops 需要一个专用的 IAM 用户来操作 AWS 资源。在已具备上述前置权限的前提下按如下步骤创建名为kops的 IAM 组与用户$ # 创建名为 kops 的 IAM 组并授予权限 $ aws iam create-group --group-name kops $ aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonEC2FullAccess --group-name kops $ aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonRoute53FullAccess --group-name kops $ aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess --group-name kops $ aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/IAMFullAccess --group-name kops $ aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonVPCFullAccess --group-name kops $ aws iam create-user --user-name kops $ aws iam add-user-to-group --user-name kops --group-name kops $ aws iam create-access-key --user-name kops最后一条命令会输出该用户的AccessKeyId与SecretAccessKey请妥善保存并通过aws configure配置到本地环境。创建 S3 状态存储桶kops 依赖一个专用的 S3 存储桶来保存集群的状态与表示state and representation。桶名需要全局唯一建议使用 FQDN 的倒写形式并附加集群的简短描述作为前缀同时务必选择你计划部署集群的 Region$ aws s3api create-bucket --bucket prefix-example-com-state-store --region us-west-2 --create-bucket-configuration LocationConstraintus-west-2 $ export KOPS_STATE_STOREs3://prefix-example-com-state-store提示--create-bucket-configuration LocationConstraintus-west-2在非 us-east-1 区域创建桶时为必填项。完成上述步骤后即可获得一个可用的集群创建环境。更详尽的 kops 安装与 AWS 配置说明可参考 kops 官方 AWS 安装文档。Cilium 前置条件在创建集群前还需要确认 Cilium 的系统级要求是否满足尤其是Linux 内核版本与键值存储key-value store版本详见 Cilium 的 系统要求文档。以当前仓库版本为例Cilium 要求Linux 内核≥ 5.10或等价版本例如 RHEL 8.10 上的 4.18键值存储etcd≥ 3.1.0。同时内核需要启用以下关键配置项发行版默认内核通常已开启CONFIG_BPFy CONFIG_BPF_EVENTSy CONFIG_BPF_SYSCALLy本指南使用的 kops 默认 AMI 已经满足 Cilium 所需的最低内核版本要求因此无需额外替换镜像。创建集群创建集群前有两个关键决策点可用区zones必须通过--master-zones和--zones分别指定 master 与 worker 节点所在可用区。master 可用区数量应为**奇数1、3…**以保证高可用为简化演示本指南将 master 与 worker 都放在同一组 3 个可用区内。gossip 协议集群为免去预先创建托管 DNS Zone 的步骤本指南使用基于 gossip 的集群。gossip 模式下集群名NAME必须以k8s.local结尾若同一个 kops 用户管理多个集群建议在名称前加上com-company-emailid-之类的前缀以保证唯一。$ export NAMEcom-company-emailid-cilium.k8s.local $ kops create cluster --state${KOPS_STATE_STORE} --node-count 3 --topology private --master-zones us-west-2a,us-west-2b,us-west-2c --zones us-west-2a,us-west-2b,us-west-2c --networking cilium --cloud-labels TeamDev,OwnerAdmin ${NAME} --yes执行过程中 kops 可能会提示你创建 SSH 公/私钥对$ ssh-keygen集群创建命令各 flag 详解Flag含义--state${KOPS_STATE_STORE}指定 kops 存储集群状态与表示的 S3 存储桶即前面创建的s3://prefix-example-com-state-store--node-count 3Kubernetes 集群中的 worker 节点数量--topology private使用私有拓扑创建集群即所有 master/node 都部署在 VPC 内的私有子网中--master-zones us-west-2a,us-west-2b,us-west-2c指定 3 个 master 节点所在的可用区分布于不同可用区以实现 HA--zones us-west-2a,us-west-2b,us-west-2cworker 节点部署所在的可用区--networking cilium指定 Cilium 作为网络 CNI 插件也可以使用cilium-etcd后者会为键值存储使用一套独立的 etcd 集群而非 CRD--cloud-labels TeamDev,OwnerAdmin应用到集群实例上的云标签${NAME}集群名称必须以k8s.local结尾以启用 gossip 集群关于--networking的补充cilium与cilium-etcd两种模式的核心区别在于 Cilium 状态的键值存储后端。默认的cilium模式将状态保存在 Kubernetes CRD 中无需额外运维 etcdcilium-etcd模式则为 Cilium 部署一套专用的 etcd 集群适用于对多集群共享状态或既有 etcd 生态有要求的场景。验证安装集群创建完成后通过以下两种方式之一验证 Cilium 是否正确安装并运行。方式一使用 Cilium CLI先安装最新版本的 Cilium CLI可用于安装 Cilium、检查安装状态以及启用/关闭 clustermesh、Hubble 等功能LinuxCILIUM_CLI_VERSION$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt) CLI_ARCHamd64 if [ $(uname -m) aarch64 ]; then CLI_ARCHarm64; fi curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum} sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin rm cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}macOSCILIUM_CLI_VERSION$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt) CLI_ARCHamd64 if [ $(uname -m) arm64 ]; then CLI_ARCHarm64; fi curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-darwin-${CLI_ARCH}.tar.gz{,.sha256sum} shasum -a 256 -c cilium-darwin-${CLI_ARCH}.tar.gz.sha256sum sudo tar xzvfC cilium-darwin-${CLI_ARCH}.tar.gz /usr/local/bin rm cilium-darwin-${CLI_ARCH}.tar.gz{,.sha256sum}随后运行状态检查命令验证 Cilium 是否已正确安装$ cilium status --wait /¯¯\ /¯¯\__/¯¯\ Cilium: OK \__/¯¯\__/ Operator: OK /¯¯\__/¯¯\ Hubble: disabled \__/¯¯\__/ ClusterMesh: disabled \__/ DaemonSet cilium Desired: 2, Ready: 2/2, Available: 2/2 Deployment cilium-operator Desired: 2, Ready: 2/2, Available: 2/2 Containers: cilium-operator Running: 2 cilium Running: 2 Image versions cilium quay.io/cilium/cilium:v1.9.5: 2 cilium-operator quay.io/cilium/operator-generic:v1.9.5: 2输出中Cilium: OK与Operator: OK表示核心组件健康DaemonSet cilium与Deployment cilium-operator的 Desired/Ready 数量一致即说明所有节点上的 agent 均已就绪。最后运行连通性测试验证集群网络是否正常工作$ cilium connectivity test ℹ️ Monitor aggregation detected, will skip some flow validation steps ✨ [k8s-cluster] Creating namespace for connectivity check... (...) --------------------------------------------------------------------------------------------------------------------- Test Report --------------------------------------------------------------------------------------------------------------------- ✅ 69/69 tests successful (0 warnings)注意连通性测试可能因某个 Pod 内打开文件过多而部署失败。若遇到此类报错可提高宿主机上的inotify资源限制后重试。方式二手动验证kubectl通过 kubectl 监控 Cilium 及相关组件在 kube-system 命名空间中的部署过程$ kubectl -n kube-system get pods --watch NAME READY STATUS RESTARTS AGE cilium-operator-cb4578bc5-q52qk 0/1 Pending 0 8s cilium-s8w5m 0/1 PodInitializing 0 7s coredns-86c58d9df4-4g7dd 0/1 ContainerCreating 0 8m57s coredns-86c58d9df4-4l6b2 0/1 ContainerCreating 0 8m57s所有组件可能需要几分钟才能完成启动最终状态应全部变为 Runningcilium-operator-cb4578bc5-q52qk 1/1 Running 0 4m13s cilium-s8w5m 1/1 Running 0 4m12s coredns-86c58d9df4-4g7dd 1/1 Running 0 13m coredns-86c58d9df4-4l6b2 1/1 Running 0 13m接下来部署连通性检查应用验证 Pod 之间的网络连通性。建议创建独立的命名空间kubectl create ns cilium-test部署检查清单kubectl apply -n cilium-test -f examples/kubernetes/connectivity-check/connectivity-check.yaml该清单位于 examples/kubernetes/connectivity-check/connectivity-check.yaml会部署一系列 Deployment通过多种连通性路径互相访问包括带/不带 Service 负载均衡以及各种网络策略组合。Pod 名称标明其连通性变体readiness 与 liveness 探针则标示测试成败$ kubectl get pods -n cilium-test NAME READY STATUS RESTARTS AGE echo-a-76c5d9bd76-q8d99 1/1 Running 0 66s echo-b-795c4b4f76-9wrrx 1/1 Running 0 66s echo-b-host-6b7fc94b7c-xtsff 1/1 Running 0 66s host-to-b-multi-node-clusterip-85476cd779-bpg4b 1/1 Running 0 66s host-to-b-multi-node-headless-dc6c44cb5-8jdz8 1/1 Running 0 66s pod-to-a-79546bc469-rl2qq 1/1 Running 0 66s pod-to-a-allowed-cnp-58b7f7fb8f-lkq7p 1/1 Running 0 66s pod-to-a-denied-cnp-6967cb6f7f-7h9fn 1/1 Running 0 66s pod-to-b-intra-node-nodeport-9b487cf89-6ptrt 1/1 Running 0 65s pod-to-b-multi-node-clusterip-7db5dfdcf7-jkjpw 1/1 Running 0 66s pod-to-b-multi-node-headless-7d44b85d69-mtscc 1/1 Running 0 66s pod-to-b-multi-node-nodeport-7ffc76db7c-rrw82 1/1 Running 0 65s pod-to-external-1111-d56f47579-d79dz 1/1 Running 0 66s pod-to-external-fqdn-allow-google-cnp-78986f4bcf-btjn7 1/1 Running 0 66s提示如果是在单节点集群上部署检查**多节点multi-node**功能的 Pod 会一直处于Pending状态。这是预期行为——这些 Pod 至少需要 2 个节点才能被成功调度。验证完成后删除测试命名空间kubectl delete ns cilium-test删除集群当不再需要集群时使用 kops 删除集群并撤销其在 AWS 上创建的全部依赖资源AutoScaling、VPC、卷等。--yes参数表示立即执行销毁而不进入确认流程$ kops delete cluster ${NAME} --yes深入kops 中 Cilium 的高级配置形态本指南仅覆盖了最基础的--networking cilium配置。kops 官方在 Cilium 网络集成上还提供了更多开箱即用的选项值得在生产环境中按需启用kube-proxy-free无 kube-proxy 模式kops 可以创建完全不含 kube-proxy 的集群由 Cilium 基于 eBPF 的 socket-LB 特性全权接管 Service 负载均衡、ClusterIP/NodePort/LoadBalancer 处理与南北向流量转发。其原理与手动配置方法详见 Kubernetes Without kube-proxy。IPAM ENI在 AWS 环境下让 Cilium 直接使用 VPC ENI 分配 Pod IP每 Pod 一个 ENI 辅助 IP与 VPC 路由表原生集成规避隧道或叠加网络的额外开销详见 IPAM ENI 文档。cilium-etcd 后端如创建集群时将--networking指定为cilium-etcdkops 会为 Cilium 部署专用 etcd 集群作为键值存储代替默认的 CRD 存储方式。进一步阅读kops 官方网络文档提供了 Cilium 在 kops 中更多配置选项的说明kops 的CiliumNetworkingSpec结构定义给出了 kops 侧所有可调参数的完整清单包括上述高级模式的开关字段。若需要从底层理解 Cilium 在节点上的运行形态可继续阅读 系统要求内核与依赖版本、Cilium Operator 内部机制以及仓库内 Cilium agent 与 Operator 的实际实现daemon/、operator/。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考