教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载导读在 Kubernetes 集群中Ingress 是集群外部流量进入集群内部的唯一“大门”而对外暴露能力的那批节点被称为边缘节点Edge Node。如果边缘节点只有单点、且入口 IP 不固定整个集群的对外服务可用性就会岌岌可危。本文以 kubernetes-handbook 仓库中的 practice/edge-node-configuration.md 为核心完整讲解如何用 keepalived 管理虚拟 IPVIP解决边缘节点单点故障并将 Traefik Ingress 改造为 DaemonSet nodeSelector hostPort 的部署形态最终实现对外只暴露一个统一入口 IP/端口、对内由多台边缘节点共同承担流量的高可用架构。读完本文你将掌握边缘节点的定义与设计要点、keepalived VRRP/VIP 配置细节、Traefik 边缘化改造步骤以及如何通过域名 Path 访问 Kubernetes 内的多个 Service。什么是边缘节点Edge Node所谓边缘节点即集群内部用来向集群外暴露服务能力的节点。集群外部的服务用户、外部系统通过该节点来调用集群内部的服务边缘节点是集群内外交流的一个 Endpoint。边缘节点的设计必须考虑两个问题边缘节点的高可用不能有单点故障否则整个 Kubernetes 集群对外将不可用对外的一致暴露端口即只能有一个外网访问 IP 和端口外部使用者不需要关心集群内部有多少台机器。这两个问题恰好是负载均衡 虚拟 IP 技术最擅长解决的场景由 keepalived 基于 VRRP 协议在多个节点间漂移一个虚拟 IPVIP对外永远只有一个稳定入口而入口背后的真实节点real_server可以是多台任一台宕机流量都会自动切换到其他存活节点。上图展示了本方案的整体架构左侧虚线框内是三台边缘节点172.20.0.113/114/115每台上运行 keepalived维护 VIP与 TraefikIngress controller右侧是 Kubernetes 集群VIP 172.20.0.119 由 keepalived 在边缘节点之间共享漂移。向集群添加 Service步骤①、更新 Ingress步骤②后将servicename.xxx.xxx:172.20.0.119记录写入 DNS步骤③集群外部即可通过 service 的 DNS 名称访问服务。架构设计keepalived 如何满足边缘节点需求为满足边缘节点的高可用与统一入口需求本方案使用keepalived来实现。其工作链路如下在 Kubernetes 中添加 Service 的同时在 DNS 中增加一条记录这条记录需要与 Ingress 中的host字段相同DNS 记录中的 IP 地址即VIP 地址本示例中为172.20.0.119集群外部通过 service 的 DNS 名称访问时流量先到达 VIP由 keepalived 承载的 LVSIPVS转发到真实的 Traefik 实例上Traefik 根据访问的host与path将流量转发到相应的 Kubernetes Service。其中VIP 是使用 IPVS 创建的IPVS 早已成为 Linux 内核的标准模块ip_vs无需额外安装这也是该方案轻量、易落地的重要原因。准备环境复用 Kubernetes 测试集群的三台主机其 IP 地址如下172.20.0.113172.20.0.114172.20.0.115本文的示例集群只有这三个 node因此在三个 node 上都需要安装 keepalived 与 ipvsadm并将它们全部指定为边缘节点。安装 keepalived 与 ipvsadm不使用容器方式安装虽然社区有 kube-keepalived-vip 容器化方案本方案更倾向于直接在 node 节点上手动安装运维直观、依赖最少yum install keepalived ipvsadm说明ipvsadm是 IPVS 的用户态管理工具用于查看和维护 LVS 规则keepalived则负责 VRRP 虚拟路由冗余VIP 漂移与 real_server 健康检查。安装完成后将三个 node 全部指定为边缘节点Edge Node。配置说明改造前需要明确的几个要点在动手配置前需要先理解本方案对原有 Traefik Ingress 部署的改造思路——将原先以Deployment方式启动的 Traefik 改为DaemonSet并指定一个与 node 在同一网段的 IP 作为 VIP。本示例将 VIP 指定为172.20.0.119配置 keepalived 前需要先保证这个 IP 没有被分配。改造后的关键特征Traefik 以DaemonSet方式启动保证每个边缘节点上都运行一个 Traefik Pod通过nodeSelector选择边缘节点只调度到打了edgenodetrue标签的节点通过hostPort暴露端口与宿主机端口直接绑定配合 LVS DR 模式直接回包当前 VIP 漂移到了172.20.0.115上主备切换时 VIP 会在三台节点间漂移Traefik 根据访问的host和path配置将流量转发到相应的 Service 上。配置 keepalivedkeepalived 的完整配置文件内容如下该文件同时保存在仓库 etc/keepalived/keepalived.conf与文档示例一致可直接参照使用! Configuration File for keepalived global_defs { notification_email { rootlocalhost } notification_email_from kaadminlocalhost smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id LVS_DEVEL } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 172.20.0.119 } } virtual_server 172.20.0.119 80{ delay_loop 6 lb_algo loadbalance lb_kind DR nat_mask 255.255.255.0 persistence_timeout 0 protocol TCP real_server 172.20.0.113 80{ weight 1 TCP_CHECK { connect_timeout 3 } } real_server 172.20.0.114 80{ weight 1 TCP_CHECK { connect_timeout 3 } } real_server 172.20.0.115 80{ weight 1 TCP_CHECK { connect_timeout 3 } } }配置块逐项解读global_defs全局定义参数作用notification_email故障告警通知邮箱本示例配置为 rootlocalhostnotification_email_from告警邮件发件人smtp_server/smtp_connect_timeoutSMTP 服务器地址与连接超时时间router_id路由标识VRID 的辅助标识同一组 keepalived 实例建议保持一致vrrp_instanceVRRP 虚拟路由实例参数作用说明state MASTER本节点初始角色多台节点配置可都写 MASTER由 priority 决定谁真正抢占也可一台 MASTER、其余 BACKUPinterface eth0VIP 绑定的物理网卡必须与节点实际网卡名一致virtual_router_id 51虚拟路由 ID同一 VRRP 组内的所有节点必须一致且同一网段内不同 keepalived 组不能冲突priority 100节点优先级数值越大越优先持有 VIP用于决定主备顺序advert_int 1VRRP 通告间隔秒主节点每秒发送一次通告备节点在超时通常 3 倍间隔后接管 VIPauth_type PASS/auth_pass 1111认证方式与密码同组节点必须一致防止非法节点抢占 VIPvirtual_ipaddress虚拟 IP 列表本示例为 172.20.0.119即对外统一入口地址virtual_serverLVS 虚拟服务参数作用delay_loop 6健康检查轮询间隔秒lb_algo loadbalance负载均衡算法本示例配置为 loadbalance轮询加权lb_kind DR转发方式为DRDirect Routing直接路由是转发效率最高的方式请求经 VIP 进入后直接路由到 real_server响应则由 real_server 直接回给客户端不经过负载均衡器nat_mask 255.255.255.0DR 模式下使用的子网掩码persistence_timeout 0会话保持时间秒0 表示不启用避免同一来源被长期固定到单台后端protocol TCP转发协议real_server ... weight 1真实后端节点即 Traefik 所在节点及其权重weight 1表示三台平均分担TCP_CHECK connect_timeout 3以 TCP 连接探测 real_server 健康状态3 秒超时后端不可用时自动从转发池中摘除其中real_server的 IP 和端口即 Traefik 供外网访问的 IP 和端口。本方案选用lb_kind DR直接路由方式转发使用TCP_CHECK来检测 real_server 的健康状态。分发配置并设置自启动将以上配置分别拷贝到另外两台 node 的/etc/keepalived目录下三台节点配置主体相同可按需调整各节点的priority以决定主备。设置 keepalived 为开机自启动chkconfig keepalived on启动 keepalived 并验证 VIP 漂移三台 node 都启动 keepalivedsystemctl start keepalived启动后观察 eth0 的 IP会在三台 node 的某一台上发现一个 VIP 是172.20.0.119$ ip addr show eth0 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state UP qlen 1000 link/ether f4:e9:d4:9f:6b:a0 brd ff:ff:ff:ff:ff:ff inet 172.20.0.115/17 brd 172.20.127.255 scope global eth0 valid_lft forever preferred_lft forever inet 172.20.0.119/32 scope global eth0 valid_lft forever preferred_lft forever如上输出所示节点172.20.0.115的 eth0 上同时出现了真实 IP 与 VIP172.20.0.119/32注意 VIP 掩码为 32 位即仅作为本机虚拟地址。验证高可用关掉拥有这个 VIP 主机上的 keepalived观察 VIP 是否漂移到了另外两台主机的其中之一上。VIP 能在秒级约 3 × advert_int 秒内自动切换到存活节点即完成了边缘节点层的单点故障消除。改造 Traefik从 Deployment 到 DaemonSet在改造之前我们启动的 Traefik 使用的是 Deployment只启动了一个 Pod无法保证高可用——单 Pod 只能固定在某一台主机上该主机一旦故障Ingress 入口即失效。现在使用 keepalived 之后就可以通过 VIP 来访问 Traefik同时启动多个 Traefik Pod保证高可用任何时刻只有持有 VIP 的节点对外应答但所有节点上的 Traefik 都在运行随时可接管。改造后的配置文件traefik.yaml与仓库 manifests/traefik-ingress/traefik.yaml 一致内容如下apiVersion: extensions/v1beta1 kind: DaemonSet metadata: name: traefik-ingress-lb namespace: kube-system labels: k8s-app: traefik-ingress-lb spec: template: metadata: labels: k8s-app: traefik-ingress-lb name: traefik-ingress-lb spec: terminationGracePeriodSeconds: 60 hostNetwork: true restartPolicy: Always serviceAccountName: ingress containers: - image: traefik name: traefik-ingress-lb resources: limits: cpu: 200m memory: 30Mi requests: cpu: 100m memory: 20Mi ports: - name: http containerPort: 80 hostPort: 80 - name: admin containerPort: 8580 hostPort: 8580 args: - --web - --web.address:8580 - --kubernetes nodeSelector: edgenode: true关键配置项解析配置项作用与说明kind: DaemonSet在每个符合条件的节点上各运行一个 Pod保证每个边缘节点都有 Traefik 实例hostNetwork: true使用宿主机网络Pod 直接共享节点网卡这是配合 LVS DR 模式real_server 直接回包的必要条件serviceAccountName: ingress使用名为ingress的 ServiceAccount赋予 Traefik 读取 Ingress/Service/Endpoints 的权限RBAC 配置见下文ports暴露 80HTTP 流量入口与 8580Traefik Web UI 管理端口两个端口均通过hostPort与宿主机端口一一绑定args: --web / --web.address:8580 / --kubernetes开启 Web UI监听 8580、启用 Kubernetes Provider使 Traefik 自动监听 Ingress 资源变化resources.limits/resources.requests资源配额上限 CPU 200m / 内存 30Mi预留 CPU 100m / 内存 20Mi保证边缘节点资源可控nodeSelector: edgenode: true只调度到打了edgenodetrue标签的边缘节点上配套 RBAC 配置Traefik 作为 Ingress controller 需要读取集群中的 Ingress、Service、Endpoints 等资源仓库提供了对应的 manifests/traefik-ingress/ingress-rbac.yaml创建一个名为ingress的 ServiceAccountnamespace: kube-system并通过 ClusterRoleBinding 将其绑定到cluster-adminClusterRole。这样 DaemonSet 中的serviceAccountName: ingress才能正常工作。给边缘节点打标签注意我们使用了nodeSelector选择边缘节点来调度 traefik-ingress-lb 运行在它上面因此需要使用以下命令给三个 node 打标签kubectl label nodes 172.20.0.113 edgenodetrue kubectl label nodes 172.20.0.114 edgenodetrue kubectl label nodes 172.20.0.115 edgenodetrue若不打标签Traefik 的 Pod 将无法匹配任何节点会一直处于Pending状态相关说明见 practice/traefik-ingress-installation.md。查看 DaemonSet 启动情况$ kubectl -n kube-system get ds NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE-SELECTOR AGE traefik-ingress-lb 3 3 3 3 3 edgenodetrue 2h三个边缘节点上都各启动了一个 Traefik Pod并且全部就绪READY 3/3。此时就可以在外网通过172.20.0.119:80来访问 Traefik Ingress 了。配置 Ingress 规则与 Traefik Web UITraefik 边缘化改造完成后还需要创建 Ingress 规则来定义流量路由。仓库中的 manifests/traefik-ingress/ingress.yaml 给出了一个多 Host Path 的示例apiVersion: extensions/v1beta1 kind: Ingress metadata: name: traefik-ingress namespace: default spec: rules: - host: traefik.nginx.io http: paths: - path: / backend: serviceName: my-nginx servicePort: 80 - host: traefik.frontend.io http: paths: - path: / backend: serviceName: frontend servicePort: 80 - host: rolling-update-test.traefik.io http: paths: - path: / backend: serviceName: rolling-update-test servicePort: 9090 - host: k8s-app-monitor-agent.jimmysong.io http: paths: - path: / backend: serviceName: k8s-app-monitor-agent servicePort: 8080 - host: mean.jimmysong.io http: paths: - path: / backend: serviceName: orbiting-platypus-mean servicePort: 80 - host: helm.jimmysong.io http: paths: - path: / backend: serviceName: monocular-monocular-ui servicePort: 80 - path: /api/ backend: serviceName: monocular-monocular-api servicePort: 80Ingress 规则的核心语义详见 concepts/ingress.md每条 rule 由hostpathbackend组成Traefik 将入站请求按 Host 头与 URL 路径进行匹配命中后转发到对应的service:portbackend中配置的是目标 namespace 中的 Service 名称与端口未显式指定 namespace 时默认使用defaultnamespace如果要在其他 namespace 中暴露服务需要新建 Ingress 文件并在其中指定namespace当集群中有新 Service 增加时修改该文件后使用kubectl replace -f ingress.yaml即可热更新路由规则若请求的 Host 无法匹配任何 rule或 URL 无法匹配任何 path流量将被转发到默认 backendIngress 中没有 rule 时的全局backend。同时可参照 manifests/traefik-ingress/ui.yaml 创建 Traefik 的 Web UI先定义一个 Selector 为k8s-app: traefik-ingress-lb的 Serviceport: 80映射到targetPort: 8580再为它创建一个host: traefik-ui.local的 Ingress。配置完成后在边缘节点上访问http://边缘节点IP:8580/即可看到 Traefik Dashboard左侧为所有 rule右侧为所有 backend。使用域名访问 Kubernetes 中的服务完成上述部署后当前集群已经具备三个边缘节点使用 Traefik 作为 Ingress controller使用 keepalived 做的 VIP虚拟 IP172.20.0.119。这样在访问该 IP 的时候通过指定不同的Host即可路由到 Kubernetes 后端服务。但这种方式访问每个 Service 时都需要显式指定Host而同一个项目中的服务一般会在同一个 Ingress 中配置使用Path来区分 Service 已经足够此时只要为 VIP172.20.0.119配置一个域名所有外部访问直接通过该域名访问即可在集群内验证路由在集群的任意一个节点上通过指定 Host 头即可验证 Traefik 的转发能力。例如访问 nginx 的/路径$ curl -H Host:traefik.nginx.io http://172.20.0.115/ !DOCTYPE html html head titleWelcome to nginx!/title ... h1Welcome to nginx!/h1 pIf you see this page, the nginx web server is successfully installed and working. Further configuration is required./p ... /htmlTraefik 会解析 HTTP 请求 header 里的Host参数将流量转发给 Ingress 配置中对应的 Service。在集群外访问配置 DNS 或 hosts如果你需要在 Kubernetes 集群以外访问就需要设置 DNS或者修改本机的 hosts 文件172.20.0.115 traefik.nginx.io 172.20.0.115 traefik.frontend.io所有访问这些地址的流量都会发送到对应节点。在生产环境即本方案的目标形态中应将该记录解析到 VIP172.20.0.119而不是某台具体节点这样才能借助 keepalived 的高可用能力——即使持有 VIP 的节点宕机DNS 指向的地址依然有效流量会在秒级内切换到新的存活边缘节点。方案要点回顾与适用前提统一入口对外永远只有一个 VIP本文示例 172.20.0.119 端口 80外部无需感知集群内部拓扑边缘节点高可用keepalived 通过 VRRP 实现 VIP 漂移LVS DR 模式 TCP_CHECK 实现后端健康检查与摘除Ingress 高可用Traefik 以 DaemonSet nodeSelector hostNetwork 部署每个边缘节点都运行实例任一节点故障由 VIP 切换接管路由能力Traefik 依据 Ingress 中的 host/path 将流量路由到不同 Service一个域名 多个 Path 即可覆盖同一项目的全部服务。适用前提与限制基于本仓库示例环境本文示例基于 CentOS 系yum install与extensions/v1beta1版本的 APIKubernetes 1.8~1.15 时代在新版本集群中应使用apps/v1的 DaemonSet 与networking.k8s.io/v1的 Ingress API但 nodeSelector hostNetwork hostPort VIP 的整体架构思路依然通用VIP 必须与 node 在同一网段且未被占用lb_kind DR模式下所有边缘节点与客户端需处于可达的二层/三层网络环境中仓库中的完整配套清单keepalived 配置 etc/keepalived/keepalived.confTraefik DaemonSet manifests/traefik-ingress/traefik.yamlRBAC manifests/traefik-ingress/ingress-rbac.yamlIngress 规则 manifests/traefik-ingress/ingress.yamlWeb UI manifests/traefik-ingress/ui.yaml相关安装流程可进一步参考 practice/traefik-ingress-installation.md。赞分享教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载相关推荐Kubernetes 手册实战Traefik Ingress Controller 配置、边缘节点路由与 Nginx 共存方案Kubernetes 手册实战Traefik Ingress Controller 配置、边缘节点路由与 Nginx 共存方案 本篇技术指南以 concept教程云原生容器编排kubernetes-handbook 实战在 Kubernetes 中部署 Linkerd 作为 Ingress Controller 与边缘路由kubernetes handbook 实战在 Kubernetes 中部署 Linkerd 作为 Ingress Controller 与边缘路由 Link教程云原生容器编排Kubernetes 集群 Master 节点高可用实践基于 Keepalived HAProxy 的 VIP 与负载均衡方案Kubernetes 集群 Master 节点高可用实践基于 Keepalived HAProxy 的 VIP 与负载均衡方案 生产环境中的 Kubern教程云原生容器编排创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考