设计要素

1. 安全性： API Server 是集群的核心控制平面，必须保证访问安全。
2. 高可用性： 接入层本身不能成为单点故障。
3. 性能： 能够承受预期的访问负载。
4. 可管理性： 配置清晰，易于维护和扩展。
5. 网络隔离： 通常建议 API Server 仅在内网可达，或通过严格控制的出口访问公网。

典型架构：Ingress + 内网 CLB

这种架构利用两者的优势：

• Ingress Controller： 提供七层 (HTTP/HTTPS) 负载均衡、TLS 终止、基于路径/域名的路由、限流等能力。常用实现如 Nginx Ingress Controller。
• 内网 CLB： 提供四层 (TCP) 负载均衡，通常具备更高的性能和稳定性，负责将流量分发到后端 Ingress Controller 的 Pod 上。它位于内网，提供了一层网络隔离。

组件角色与流量路径

graph LR
    subgraph Kubernetes Cluster
        IC[Ingress Controller Pods] -->|ClusterIP Service| APIS[API Server Pods]
    end
    CLB[内网 CLB VIP] -->|TCP 流量| IC
    Client[客户端 kubectl, etc.] -->|HTTPS 请求| CLB

1. 客户端请求： 用户或系统组件 (如 kubectl, 集群内组件，其他服务) 发起 HTTPS 请求到 内网 CLB 的 VIP。
2. CLB 负载均衡： 内网 CLB 根据配置的负载均衡算法 (如轮询、最小连接数) 将 TCP 连接 分发到后端的 Ingress Controller Pod 所在的节点。CLB 的健康检查确保只将流量发给健康的节点/Pod。
3. Ingress 处理：
   • TLS 终止： Ingress Controller 接收 HTTPS 流量，使用配置的 TLS 证书进行解密 (TLS Termination)。
   • 路由： 根据 Ingress 资源定义的规则 (通常是基于 Host 或特定 Path)，将请求路由到对应的 Kubernetes Service。这里的目标 Service 是 API Server 的 Service (通常是 kubernetes Service，类型为 ClusterIP，暴露端口 443)。
   • 其他能力： 可能应用限流、日志记录、重写规则等。
4. Kubernetes Service: 请求到达 kubernetes Service (ClusterIP)。
5. kube-proxy 和 Endpoints: kube-proxy 根据 Service 关联的 Endpoints (即健康的 API Server Pod 的 IP 列表) 进行负载均衡，将请求转发到某个 API Server Pod。
6. API Server 处理： API Server Pod 处理请求，进行认证、授权、准入控制等，并返回响应。响应沿原路径返回给客户端。

关键配置与考虑

1. Ingress 资源定义：

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: kube-apiserver-ingress
     namespace: kube-system # 或其他合适的命名空间
     annotations:
       # Nginx Ingress 示例注解
       nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" # 告知 Nginx 后端 API Server 使用 HTTPS
       nginx.ingress.kubernetes.io/proxy-ssl-secret: "kube-system/apiserver-proxy-cert" # (可选) 用于与 API Server 双向 TLS 的证书
       nginx.ingress.kubernetes.io/proxy-ssl-verify: "on" # (可选) 启用对 API Server 证书的验证
       # 其他可能的注解：限流、日志等
   spec:
     tls:
     - hosts:
       - kube-api.mycluster.internal # 用于访问 API Server 的域名
       secretName: apiserver-ingress-cert # 存储 TLS 证书的 Secret
     rules:
     - host: kube-api.mycluster.internal
       http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: kubernetes # 指向 kube-apiserver 的 Service
               port:
                 number: 443
   

2. 内网 CLB 配置：

   • 监听协议端口： TCP/443
   • 后端服务器： 添加运行 Ingress Controller Pod 的 Kubernetes Node 作为后端服务器。通常添加所有 Worker Node（确保 Controller Pod 能调度到这些节点），并配置健康检查端口（如 Ingress Controller 暴露的 :10254 /healthz）。
   • 会话保持： 对于 kubectl exec/logs 等长连接操作，可能需要配置合适的会话保持策略（如基于源 IP）。
   • 访问控制： 在 CLB 层面配置 ACL/Security Group，仅允许特定的客户端 IP 段访问 443 端口。

3. API Server Service (kubernetes)：

   • 确保其存在且类型为 ClusterIP，端口映射正确 (443 -> 443)。
   • 确保 Endpoints 列表 (kubectl get endpoints kubernetes -n default) 包含所有健康的 API Server 实例的 IP 和端口。

4. DNS： 为 kube-api.mycluster.internal 配置内网 DNS 解析，指向内网 CLB 的 VIP。

5. 安全性强化：

   • 证书管理： 妥善管理 Ingress 的 TLS 证书 (apiserver-ingress-cert) 和（可选的）用于与 API Server 通信的证书 (apiserver-proxy-cert)。
   • 网络策略： 使用 NetworkPolicy 限制哪些 Pod 可以访问 Ingress Controller 和 API Server。
   • API Server 认证： Kubernetes API Server 本身的 RBAC、认证插件 (e.g., x509, Token, Webhook) 等配置是安全的最后防线。

优势

• 安全隔离： CLB 位于内网，限制了直接暴露范围；Ingress 提供 TLS 终止和灵活的七层安全策略。
• 高可用： CLB + Ingress Controller 多副本 + API Server 多副本，提供了多层冗余。
• 灵活性： Ingress 的注解提供了丰富的配置选项（限流、日志、重定向等）。
• 标准化： 利用熟悉的 Ingress 模式来管理 API 访问。
• 
   

验证与监控

1. 连通性测试： 使用 kubectl 或 curl 通过 CLB VIP 或域名访问 API Server。
2. 健康检查： 监控 CLB 健康检查状态、Ingress Controller Pod 状态、API Server Pod 状态。
3. 日志审计： 查看 Ingress Controller 和 API Server 的日志，确保访问正常且符合预期。
4. 性能监控： 监控 CLB 连接数、带宽，Ingress Controller 和 API Server 的 CPU/Memory 使用率，请求延迟等。

总结

结合 Ingress 和内网 CLB 为 Kubernetes API Server 构建接入层，是一种兼顾安全性、高可用性和可管理性的常见方案。Ingress 负责七层流量处理和高级功能，内网 CLB 提供稳定的四层负载和网络隔离。关键在于正确配置三者（CLB, Ingress, API Server Service）之间的协同工作，并实施严格的安全措施。