为AKS集群API Server配置静态IP：Nginx四层代理配置后kubectl执行报错求助

云上老周

2026-4-16

AKS集群API Server配置静态IP：Nginx四层代理配置后kubectl执行报错求助

看起来你遇到的问题主要来自两个核心点：端口映射不匹配导致的连接不通，以及AKS API Server证书域名不匹配引发的验证失败，我来一步步帮你排查解决：

一、先排查端口映射问题

你当前的Nginx配置里监听的是6443端口，但你的kubeconfig中server字段是https://k8-jumpbox.example.com——HTTPS默认走443端口，这就导致kubectl尝试连接的端口和Nginx实际监听的端口不匹配，直接引发连接超时或者EOF错误。

解决办法二选一：

调整Nginx的监听端口为443：修改stream块里的server配置：
```
server {
    listen 443;
    proxy_pass k8s_servers;
}
```
注意：需要确保VM的443端口没有被其他服务占用，同时在Azure防火墙/VM的网络安全组（NSG）中开放443端口的入站规则。

或者修改kubeconfig的server地址，显式指定6443端口：

- cluster:
    certificate-authority-data: XXXXXX
    server: https://k8-jumpbox.example.com:6443

二、处理证书域名不匹配的问题

即使端口问题解决了，你大概率会遇到新的证书验证错误——因为AKS API Server的SSL证书是颁发给它的默认域名（比如example1234.hcp.eastus.azmk8s.io）的，而你通过自定义域名k8-jumpbox.example.com访问时，kubectl会验证证书的域名是否一致，这一步会失败，导致连接中断。

这里有几个可行的解决方案，按安全性从高到低排序：

方案1：配置Nginx做七层反向代理并处理SSL

把Nginx从四层流代理改成HTTPS反向代理，这样可以在Nginx层面终止SSL，同时用自定义域名的证书和客户端（kubectl）通信，然后Nginx再用AKS的默认域名去访问API Server（此时Nginx会验证AKS的证书）。

修改Nginx配置为：

http {
    upstream k8s_api {
        server example1234.hcp.eastus.azmk8s.io:443;
    }

    server {
        listen 443 ssl;
        server_name k8-jumpbox.example.com;

        # 这里配置你的自定义域名的SSL证书
        ssl_certificate /path/to/your/cert.pem;
        ssl_certificate_key /path/to/your/private.key;

        location / {
            proxy_pass https://k8s_api;
            # 透传Host头，让AKS API Server识别正确的请求域名
            proxy_set_header Host example1234.hcp.eastus.azmk8s.io;
            # 透传必要的请求头
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

同时，kubeconfig中的certificate-authority-data需要换成你自定义域名证书的CA数据，或者如果用的是公开CA颁发的证书，可以去掉这个字段（kubectl会自动信任）。

方案2：临时禁用kubectl的证书验证（不推荐用于生产环境）

如果只是测试用途，可以临时关闭kubectl的证书验证来绕开域名不匹配的问题，修改kubeconfig的cluster部分：

- cluster:
    insecure-skip-tls-verify: true
    server: https://k8-jumpbox.example.com:6443

注意：这个方法会让你的kubectl连接失去SSL证书验证的保护，存在安全风险，生产环境绝对不要用。

方案3：确保AKS API Server允许代理VM的IP访问

另外，别忘了检查AKS集群的API Server授权IP范围——如果你的AKS配置了只允许特定IP访问API Server，需要把Nginx VM的公网IP加入到这个授权列表中，否则AKS会拒绝来自VM的请求，也会导致连接超时或EOF。

三、验证代理连通性的小技巧

在调整配置后，可以先用curl测试连通性：

在Nginx VM上执行：curl -v https://example1234.hcp.eastus.azmk8s.io:443/version，确认能正常返回API Server的版本信息。
在本地机器上执行：curl -v https://k8-jumpbox.example.com:6443/version（或者对应你调整后的端口），如果能返回相同的版本信息，说明代理已经正常工作，再用kubectl尝试操作。

备注：内容来源于stack exchange，提问作者Ryan Grush