Ingress-NGINX Controller
K8S版本为1.29.13
ingress-nginx1.10.0
nginx版本1.25.3
其他
https://github.com/nginx/kubernetes-ingress
Ingress-NGINX Controller for Kubernetes
https://gitcode.com/gh_mirrors/in/ingress-nginx?utm_source=csdn_blog_hover&isLogin=1
一、Ingress简介
https://cloud.tencent.com/developer/article/1903063
Ingress是Kubernetes中的一个抽象层，用于将多个服务公开到同一IP地址和端口，并根据请求路径或主机名进行路由，而网关则是提供对应用程序的访问控制、身份验证、安全性、流量管理和监视等功能的组件，它可以与Kubernetes集群一起使用，但也可以独立于Kubernetes集群之外部署。
Ingress 可以解决什么问题
https://blog.51cto.com/u_13521/9656645
1.动态配置服务
如果按照传统方式, 当新增加一个服务时, 我们可能需要在流量入口加一个反向代理指向我们新的k8s服务. 而如果用了Ingress, 只需要配置好这个服务, 当服务启动时, 会自动注册到Ingress的中, 不需要而外的操作.
2.减少不必要的端口暴露
配置过k8s的都清楚, 第一步是要关闭防火墙的, 主要原因是k8s的很多服务会以NodePort方式映射出去, 这相当于给宿主机打了很多孔, 既不安全也不优雅. 而Ingress可以避免这个问题, 除了Ingress自身服务可能需要映射出去, 其他服务都不要用NodePort方式
ingress可以提供7层的负责对外暴露接口，而且可以调度不同的业务域，不同的url访问路径的业务流量。
Ingress：K8s 中的一个资源对象，作用是定义请求如何转发到 service 的规则
Ingress Controller：具体实现反向代理及负载均衡的程序，对Ingress定义的规则进行解析，根据配置的规则来实现请求转发，有很多种实现方式，如 Nginx、Contor、Haproxy等
Ingress 基本原理图
ingress 组成
ingress controller：将新加入的Ingress转化成Nginx的配置文件并使之生效。
ingress服务：将Nginx的配置抽象成一个Ingress对象，每添加一个新的服务只需写一个新的Ingress的yaml文件即可
Ingress 工作原理
1.ingress controller通过和kubernetes api交互，动态的去感知集群中ingress规则变化。
2.然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段nginx配置。
3.再写到nginx-ingress-control的pod里，这个Ingress controller的pod里运行着一个Nginx服务，控制器会把生成的nginx配置写入/etc/nginx.conf文件中。
4.然后reload一下使配置生效。以此达到域名分配置和动态更新的问题。
版本对照表
部署 ingress-nginx
1、下载nginx-ingress-controller配置文件
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.10.0/deploy/static/provider/cloud/deploy.yaml
2、修改源文件中的镜像地址
[root@master ~]$ vi deploy.yaml
registry.k8s.io/ingress-nginx/controller:v1.10.0@sha256:42b3f0e5d0846876b1791cd3afeb5f1cbbe4259d6f35651dcc1b5c980925379c
替换成
registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:v1.10.0
registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.4.0@sha256:44d1d0e9f19c63f58b380c5fddaca7cf22c7cee564adeff365225a5df5ef3334
替换成
registry.aliyuncs.com/google_containers/kube-webhook-certgen:v1.4.0
注：可使用docker pull 拉取
spec:
hostNetwork: true #与宿主机共享网络
tolerations: #设置能在master上部署
- key: node-role.kubernetes.io/master
operator: Exists
containers:
- args:
- /nginx-ingress-controller
- --publish-service=$(POD_NAMESPACE)/ingress-nginx-controller
- --election-id=ingress-nginx-leader
- --controller-class=k8s.io/ingress-nginx
- --ingress-class=nginx
- --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
- --validating-webhook=:8443
- --validating-webhook-certificate=/usr/local/certificates/cert
- --validating-webhook-key=/usr/local/certificates/key
暴漏ingress的80端口，在“deploy.yaml”中的415行下添加“hostNetwork: true”。
设置pod的控制器，将“deploy.yaml”中“kind: Deployment”改为“kind: DaemonSet”。
...
下载镜像
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:v1.10.0
docker pull registry.aliyuncs.com/google_containers/kube-webhook-certgen:v1.4.0
docker pull registry.openanolis.cn/openanolis/nginx:1.14.1-8.6
3、执行yaml文件部署
[root@master ~]$ kubectl apply -f deploy.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
serviceaccount/ingress-nginx-admission created
role.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
configmap/ingress-nginx-controller created
service/ingress-nginx-controller created
service/ingress-nginx-controller-admission created
deployment.apps/ingress-nginx-controller created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
ingressclass.networking.k8s.io/nginx created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created
部署文件介绍
1.namespace.yaml 创建一个独立的命名空间 ingress-nginx
2.configmap.yaml
ConfigMap是存储通用的配置变量的，类似于配置文件，使用户可以将分布式系统中用于不同模块的环境变量统一到一个对象中管理；而它与配置文件的区别在于它是存在集群的“环境”中的，并且支持K8S集群中所有通用的操作调用方式。
从数据角度来看，ConfigMap的类型只是键值组，用于存储被Pod或者其他资源对象（如RC）访问的信息。这与secret的设计理念有异曲同工之妙，主要区别在于ConfigMap通常不用于存储敏感信息，而只存储简单的文本信息。
ConfigMap可以保存环境变量的属性，也可以保存配置文件。
创建pod时，对configmap进行绑定，pod内的应用可以直接引用ConfigMap的配置。相当于configmap为应用/运行环境封装配置。
pod使用ConfigMap，通常用于：设置环境变量的值、设置命令行参数、创建配置文件。
3.default-backend.yaml
如果外界访问的域名不存在的话，则默认转发到default-http-backend这个Service，其会直接返回404：
4.rbac.yaml
负责Ingress的RBAC授权的控制，其创建了Ingress用到的ServiceAccount、ClusterRole、Role、RoleBinding、ClusterRoleBinding
5.with-rbac.yaml
是Ingress的核心，用于创建ingress-controller。前面提到过，ingress-controller的作用是将新加入的Ingress进行转化为Nginx的配置
4、查看ingress-nginx组件状态
[root@master ~]# kubectl get pods -n ingress-nginx #查看pod状态
NAME READY STATUS RESTARTS AGE
ingress-nginx-admission-create-hb8r6 0/1 Completed 0 66s
ingress-nginx-admission-patch-mm6l9 0/1 Completed 0 66s
ingress-nginx-controller-5f4db6b476-n4gjr 1/1 Running 0 66s
#查看创建的ingress service暴露的端口
[root@master ~]# kubectl get svc -n ingress-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx-controller LoadBalancer 10.100.131.62 <pending> 80:31057/TCP,443:31682/TCP 102s
ingress-nginx-controller-admission ClusterIP 10.102.117.206 <none> 443/TCP 102s
get all
[root@master nginx]# kubectl get all -n ingress-nginx -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/ingress-nginx-admission-create-hb8r6 0/1 Completed 0 32m 10.244.166.188 node1 <none> <none>
pod/ingress-nginx-admission-patch-mm6l9 0/1 Completed 0 32m 10.244.166.189 node1 <none> <none>
pod/ingress-nginx-controller-5f4db6b476-n4gjr 1/1 Running 0 32m 10.0.0.58 node1 <none> <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/ingress-nginx-controller LoadBalancer 10.100.131.62 <pending> 80:31057/TCP,443:31682/TCP 32m app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx
service/ingress-nginx-controller-admission ClusterIP 10.102.117.206 <none> 443/TCP 32m app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
deployment.apps/ingress-nginx-controller 1/1 1 1 32m controller registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:v1.10.0 app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
replicaset.apps/ingress-nginx-controller-5f4db6b476 1 1 1 32m controller registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:v1.10.0 app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx,pod-template-hash=5f4db6b476
NAME COMPLETIONS DURATION AGE CONTAINERS IMAGES SELECTOR
job.batch/ingress-nginx-admission-create 1/1 8s 32m create registry.aliyuncs.com/google_containers/kube-webhook-certgen:v1.4.0 batch.kubernetes.io/controller-uid=986ebb56-86dd-43c3-9b6c-2798922584c9
job.batch/ingress-nginx-admission-patch 1/1 8s 32m patch registry.aliyuncs.com/google_containers/kube-webhook-certgen:v1.4.0 batch.kubernetes.io/controller-uid=a38f3b36-be8c-474e-bdea-e4e4644b9cea
访问ingress-nginx服务，查看是否配置成功
http://172.33.16.241:32080 -----未测试
[root@master nginx]# curl 10.100.131.62
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
创建Deployment、Service
[root@master nginx]# cat nginx-deployment.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: registry.openanolis.cn/openanolis/nginx:1.25.3
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
volumeMounts:
- mountPath: "/etc/nginx/nginx.conf"
name: conf
- mountPath: "/etc/nginx/conf.d/"
name: confd
- mountPath: "/var/log/nginx/"
name: log
- mountPath: "/usr/share/nginx/html"
name: html
volumes:
- name: conf
hostPath:
path: /home/nginx/conf/nginx.conf
- name: confd
hostPath:
path: /home/nginx/conf/conf.d/
- name: log
hostPath:
path: /home/nginx/log/
- name: html
hostPath:
path: /home/nginx/html/
nodeName: master #指定节点运行
svc
[root@master nginx]# cat nginx-svc.yml
apiVersion: v1
kind: Service
metadata:
name: nginx
namespace: default
labels:
app: nginx
spec:
type: ClusterIP
ports:
- protocol: TCP
port: 80 #service暴露在cluster ip上的端口
targetPort: 80 #pod上的端口
selector:
app: nginx
创建ingress文件
https://blog.youkuaiyun.com/huaz_md/article/details/143234028
TLS类型的Ingress资源
TLS类型的Ingress资源用于以HTTPS发布Service资源，基于一个含有私钥和证书的Secret对象即可配置TLS协议的Ingress资源。Ingress资源目前仅支持单TLS端口
基于域名的访问
建立基于域名的ingress-https.yaml文件
下载 cert-manager
kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.6.1/cert-manager.yaml
使用ingress发布服务
在ingress控制器上配置HTTPS主机时，是不能直接使用私钥和证书文件的，而是要使用Secret资源对象来传递相关的数据。
创建TLS密钥和证书
你需要一个 TLS 证书来加密通过443端口的通信。你可以使用 Let’s Encrypt 或阿里云的 SSL 证书服务来获取证书。
创建各自域名自签名的证书（生产环境直接使用购买的证书即可）
#生成证书
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=yourdomain.com"
创建Secret
创建TLS类型的secret资源
# 创建证书
[root@master home]# kubectl create secret tls www-tls-secret --key tls.key --cert tls.crt
secret/www-tls-secret created
办法2：使用yaml文件来创建 TLS Secret
[root@k8s-master ~]# vi tomcat-tls-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: tomcat-tls-secret
namespace: default
type: kubernetes.io/tls
data:
tls.crt: base64 编码的 cert
tls.key: base64 编码的 key
详情
[root@master home]# kubectl describe secrets www-tls-secret
Name: www-tls-secret
Namespace: default
Labels: <none>
Annotations: <none>
Type: kubernetes.io/tls
Data
====
配置Ingress资源
建立基于tls认证的Ingress文件
[root@master ~]# kubectl apply -f ingress-https.yml
创建一个https访问模式的ingress规则yaml文件
[root@master ~]# cat ingress-https.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-https
spec:
ingressClassName: nginx
tls:
- hosts:
- www.yaodomain.cn
secretName: www-tls-secret
rules:
- host: www.yaodomain.cn
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx
port:
number: 80
查看创建的ingress规则，多了443端口
[root@master nginx]# kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
ingress-api nginx api.yourdomain.cn 80, 443 10h
ingress-https nginx www.yourdomain.cn 80, 443 11h
域名访问
查看详情
[root@k8s-master ~]# kubectl describe ingress ingress-https
Name: ingress-https
Labels: <none>
Namespace: default
Address:
Ingress Class: nginx
Default backend: <default>
TLS:
www-tls-secret terminates www.yourdomain.cn
Rules:
Host Path Backends
---- ---- --------
www.yourdomain.cn
/ nginx:80 (10.244.219.87:80)
Annotations: <none>
Events: <none>
5、查看ingress-default-backend的详细信息
进入nginx pod
kubectl exec -it -n ingress-nginx ingress-nginx-controller-64dcb8c779-w5tq9 /bin/sh
参考资料
kubernetes中的ingress-nginx
https://blog.youkuaiyun.com/huaz_md/article/details/143234028
k8s-访问外网服务的两种方式 https://www.jianshu.com/p/deaa98210827
Kubernetes 配置之Secret https://zhuanlan.zhihu.com/p/568460299
Kubernetes详解（四十一）——Secret创建
https://blog.youkuaiyun.com/weixin_40228200/article/details/124486360
https://so.youkuaiyun.com/so/search?q=kubernetes&t=blog&u=weixin_40228200
其他
打印某个 pod 的环境变量
kubectl exec {pod名称} {要执行的命令}
打印某个 pod 的环境变量
kubectl exec nginx-585449566-d2fdc -- pritenv
# kubectl exec nginx-585449566-d2fdc env
hosts 解析
cat >> /etc/hosts << 'EOF'
180.163.83.192 www.yao10.com
180.163.83.192 api.yao10.com
EOF
#编辑操作
[root@master service]# kubectl edit svc ingress-nginx-controller -n ingress-nginx
Ingress TLS 域名配置流程（询问DeepSeek AI）
k8s1.29中使用Ingress1.10.0的 Ingress 的 TLS 配置 和 HTTPS配置，可以在云平台在外网域名访问 https://api.yao10.cn 端口443
K8S Ingress 的 TLS 配置：通过 Ingress 暴露的 HTTPS 服务需配置 TLS 证书。
分析以下几个方面：
1. **TLS证书的获取和管理**：用户需要为域名api.yao10.cn获取有效的TLS证书。常见的做法是使用Let's Encrypt的免费证书，或者使用自签名证书（仅测试环境）。用户可能需要使用cert-manager来自动化管理证书，或者手动创建Secret。
2. **Ingress资源配置**：在Ingress的YAML文件中，需要配置TLS部分，引用存储证书的Secret，并正确设置规则，将HTTPS流量路由到后端的Service。
3. **Service和Pod的配置**：确保后端Service正确指向Pod，并且Pod内的应用能够处理HTTPS请求（如果需要）。不过，通常Ingress-Nginx会处理SSL终止，将解密后的HTTP请求转发到后端服务，因此后端服务可能不需要处理HTTPS。
4. **防火墙和云平台配置**：确认云平台的负载均衡器是否正确配置了HTTPS监听器，将443端口的流量转发到Ingress控制器的80端口（如果使用SSL终止），或者正确配置其他端口映射。同时，确保安全组规则允许443端口的入站流量。
5. **DNS配置**：确保域名api.yao10.cn的DNS记录正确指向了Ingress控制器的公网IP地址。如果用户之前已经配置了A记录指向180.163.83.192，并且该IP已正确关联到Ingress控制器，那么这一步可能已经完成。
可能的陷阱或常见问题：
- **证书不匹配**：证书的Common Name或Subject Alternative Names (SANs) 必须与域名api.yao10.cn完全一致，否则浏览器会报错。
- **Secret命名空间和名称**：在Ingress资源中引用的TLS Secret必须存在于相同的命名空间中，且名称正确。
- **Ingress控制器配置**：确保Ingress控制器配置了正确的TLS终止，并且监听了443端口。
- **HTTP到HTTPS重定向**：可能需要配置Ingress规则，将HTTP（80端口）的流量自动重定向到HTTPS（443端口）。
总结，配置步骤可能包括：
1. 生成或获取TLS证书（自签名或Let's Encrypt）。
2. 创建Kubernetes Secret存储证书。
3. 更新Ingress资源，添加TLS配置，引用该Secret。
4. 配置Ingress-Nginx以处理HTTPS请求，并可能设置HTTP到HTTPS的重定向。
5. 确保云平台负载均衡器正确转发443端口的流量到Ingress控制器的443端口。
6. 测试HTTPS访问，确保证书有效，配置正确。
在用户的实际操作中，可能会遇到证书不被信任（自签名证书）、Secret配置错误、端口映射不正确等问题，需要逐步排查。
以下是在 Kubernetes 1.29 中使用 Ingress-Nginx 1.10.0 配置 TLS 和 HTTPS 的详细步骤，确保通过公网域名 https://api.yao10.cn（端口 80 自动跳转 443）安全访问服务：
1. 准备工作
1.1 确认 Ingress 控制器已正确暴露
确保 Ingress-Nginx 的 Service 类型为 LoadBalancer 或 NodePort，并已分配公网 IP（如 180.163.83.192）。
kubectl get svc -n ingress-nginx
输出应类似：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx-controller LoadBalancer 10.96.1.2 180.163.83.192 80:32750/TCP,443:32415/TCP 5d
1.2 域名解析检查
确认 api.yao10.cn 的 DNS A 记录指向 180.163.83.192：
nslookup api.yao10.cn
预期输出：
Name: api.yao10.cn
Address: 180.163.83.192
2. 配置 TLS 证书
2.1 生成或获取证书
- Let’s Encrypt（生产推荐）：使用
cert-manager自动申请证书。 - 自签名证书（测试用）：
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=yourdomain.con"
2.2 创建 TLS Secret
将证书保存到 Kubernetes Secret：
kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key -n <your-namespace>
# 示例（假设应用在 default 命名空间）：
kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key -n default
3. 配置 Ingress 资源
3.1 编写 Ingress YAML
创建 my-ingress.yaml，配置 TLS 和 HTTPS 路由：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
nginx.ingress.kubernetes.io/force-ssl-redirect: "true" # 强制 HTTP 跳转 HTTPS
spec:
ingressClassName: nginx
tls:
- hosts:
- api.yao10.cn
secretName: tls-secret # 引用 TLS Secret
rules:
- host: api.yao10.cn
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-service # 替换为你的 Service 名称
port:
number: 80
3.2 应用配置
kubectl apply -f my-ingress.yaml
4. 验证 HTTPS 配置
4.1 检查 Ingress 状态
kubectl describe ingress my-ingress
输出应显示 TLS 配置和规则：
TLS:
tls-secret terminates api.yao10.cn
Rules:
Host Path Backends
---- ---- --------
api.yao10.cn
/ nginx-service:80 (10.244.219.74:8080)
4.2 测试 HTTPS 访问
curl -vk https://api.yao10.cn/api/login/getCurrentUser
- 如果使用自签名证书，添加
-k忽略证书验证。 - 预期输出为后端服务的响应。
5. 云平台负载均衡器配置
5.1 配置负载均衡器监听器
- 端口映射：
- 外部
443→ Ingress Service 的443端口。 - 外部
80→ Ingress Service 的80端口（用于自动跳转 HTTPS）。
- 外部
5.2 安全组规则
确保云平台安全组允许以下入站流量：
- 端口
80（HTTP）和443（HTTPS）。
6. 高级配置（可选）
6.1 自动证书管理（cert-manager）
-
安装 cert-manager：
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.1/cert-manager.yaml -
创建 ClusterIssuer（以 Let’s Encrypt 为例）：
apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-prod spec: acme: server: https://acme-v02.api.letsencrypt.org/directory email: your-email@example.com privateKeySecretRef: name: letsencrypt-prod solvers: - http01: ingress: class: nginx -
更新 Ingress 注解以自动申请证书：
metadata: annotations: cert-manager.io/cluster-issuer: letsencrypt-prod
常见问题排查
1. 证书错误（如 SSL_ERROR_BAD_CERT_DOMAIN）
- 原因：证书域名与请求的域名不匹配。
- 解决：确保证书的 Common Name 或 SANs 包含
api.yao10.cn。
2. HTTPS 访问返回 503
- 原因：Ingress 后端 Service 未就绪或端口映射错误。
- 解决：
kubectl describe svc my-service kubectl get endpoints my-service
3. HTTP 未自动跳转 HTTPS
- 解决：检查 Ingress 注解
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"。
总结
通过上述步骤，你的服务已通过 HTTPS 安全暴露，用户可通过 https://api.yao10.cn 访问。关键点包括：
- 证书管理：手动创建 Secret 或使用 cert-manager 自动化。
- Ingress 配置：强制 HTTP 跳转 HTTPS，并关联 TLS Secret。
- 云平台集成：确保负载均衡器正确转发 80/443 端口流量。
问题：关于配置微服务Gateway的域名接口，公网域名无法访问k8s中的Java服务的问题
DeepSeek的问题分析
公网域名无法访问Kubernetes中的Java服务的问题。用户已经详细描述了他们的配置和遇到的问题，我需要一步步分析可能的原因，并提供解决方案。
首先，用户提到在内网中可以直接通过Pod的IP和端口访问服务，但通过公网域名和端口访问失败。这说明Pod和Service的配置可能是正确的，问题可能出在Ingress、DNS解析、端口映射或网络配置上。
1. **域名解析问题**：
- 用户提到域名未正确解析到Ingress入口IP。需要确认域名是否指向了正确的公网IP。用户需要检查DNS设置，确保api.yao10.cn的A记录指向了Kubernetes节点的公网IP或负载均衡器的IP。
2. **Ingress配置检查**：
- 用户配置了Ingress资源，指定了host为api.yao10.cn，端口为9999。需要检查Ingress的配置是否正确，特别是Service的端口是否匹配，以及Ingress控制器是否正确处理该配置。确保Ingress资源中指定的Service名称和端口与实际创建的Service一致。
3. **Service配置验证**：
- 确认Service的selector是否与Pod的标签匹配，确保Service能够正确路由到Pod。使用`kubectl get endpoints`检查Service是否有正确的端点。
4. **Ingress控制器暴露方式**：
- Ingress控制器（ingress-nginx）需要以某种方式暴露到公网，通常是通过NodePort、LoadBalancer或外部负载均衡器。如果用户使用的是NodePort，需要确保节点的公网IP和NodePort端口（通常为30000-32767范围）在防火墙中开放，并且域名解析到节点的IP和正确的NodePort端口。
5. **端口冲突或配置错误**：
- Ingress控制器通常监听80和443端口，用户的Java服务使用9999端口。如果Ingress配置中指定了端口9999，需要确认Ingress控制器是否实际监听该端口，或者是否需要进行端口映射。例如，外部流量通过80端口进入，然后Ingress将请求路由到Service的9999端口。
6. **防火墙和安全组设置**：
- 检查云服务提供商的安全组规则或本地防火墙设置，确保公网IP的9999端口允许入站流量。如果使用NodePort，需要开放对应的NodePort端口，而不是9999。
7. **Ingress控制器日志检查**：
- 查看Ingress控制器的日志，确认是否有错误信息，例如配置无法加载、证书问题或路由错误。使用`kubectl logs`命令获取日志。
8. **测试直接通过节点IP和NodePort访问**：
- 用户可以通过节点的公网IP和NodePort端口直接访问服务，绕过域名解析，以确定问题是否出在DNS。例如，使用`curl http://节点IP:NodePort/api/login/getCurrentUser`。
9. **检查Ingress的annotations和配置**：
- 确保没有遗漏必要的annotations，例如是否启用了CORS或需要设置其他Nginx参数。例如，确保路径匹配正确，没有使用正则表达式导致路由失败。
10. **HTTPS与HTTP混合问题**：
- 如果服务配置了HTTPS，但用户使用HTTP访问，或者证书配置不正确，可能导致访问失败。检查是否需要配置TLS证书，或强制HTTP到HTTPS的重定向。
根据用户提供的信息，可能的问题点在于域名解析未正确指向Ingress控制器的公网入口，或者Ingress控制器未正确暴露9999端口。例如，如果Ingress控制器通过NodePort暴露，用户需要将域名指向节点IP，并使用NodePort端口（如31000），而不是直接使用9999端口。或者，用户可能误将Service的端口与Ingress的端口混淆，导致外部流量无法正确路由。
总结可能的解决步骤：
- 检查域名DNS解析是否正确指向Kubernetes节点的公网IP或负载均衡器的IP。
- 确认Ingress控制器的服务类型（如NodePort或LoadBalancer）及其暴露的端口。
- 确保外部流量通过正确的端口（如NodePort）访问，并验证防火墙规则。
- 检查Ingress资源的配置，确保host、路径和Service端口正确。
- 使用`kubectl get ingress`查看Ingress的ADDRESS字段，确认其是否获取了正确的入口IP。
- 测试通过节点IP和NodePort直接访问，确认服务是否可达。
最终，用户可能需要调整Ingress控制器的服务类型为LoadBalancer（如果云环境支持），并确保域名解析到LoadBalancer的IP，或者正确配置NodePort并开放相应端口。
完
K8S的TLS是什么，怎样使用（询问 DeepSeek AI的问题）
Kubernetes（k8s）使用 TLS（Transport Layer Security） 是为了确保集群内外的通信安全，防止数据泄露、篡改和中间人攻击。以下是 TLS 在 Kubernetes 中的核心作用及具体应用场景：
1. 加密通信
TLS 对 Kubernetes 组件之间的通信进行加密，保护敏感数据（如认证令牌、配置信息、Pod 日志等）不被窃取。
- 核心场景：
- API Server 与客户端（如 kubectl）：所有通过 HTTPS 的请求和响应均加密。
- API Server 与 etcd：API Server 与 etcd 存储集群状态数据的通信需加密。
- 节点间通信：kubelet、kube-proxy 与 API Server 的交互需加密。
- Service 流量：通过 Ingress 暴露的 HTTPS 服务（如 Web 应用）使用 TLS 证书。
2. 身份认证（Authentication）
TLS 证书用于验证组件或用户的身份，确保只有授权的实体可以访问集群资源。
- 核心场景：
- 组件间认证：
- API Server 验证 kubelet、scheduler、controller-manager 的客户端证书。
- etcd 验证 API Server 的客户端证书。
- 用户认证：
- kubectl 使用客户端证书或 Token 向 API Server 证明身份。
- Service Account：Pod 内应用通过 TLS 证书与 API Server 安全通信。
- 组件间认证：
3. 数据完整性
TLS 确保传输的数据未被篡改，防止中间人攻击（MITM）。
- 核心场景：
- 配置下发：确保 kubelet 收到的 Pod 定义来自合法的 API Server。
- Secret 传输：加密敏感信息（如密码、密钥）的传输过程。
Kubernetes 中 TLS 的具体应用
1. API Server 的 TLS 配置
API Server 是集群的“网关”，所有请求必须通过 TLS 加密和认证。
- 服务端证书：API Server 使用 TLS 证书对外提供 HTTPS 服务。
- 客户端证书：
kubectl、kubelet 等组件需提供有效证书才能访问 API Server。
# API Server 启动参数示例（/etc/kubernetes/manifests/kube-apiserver.yaml）
spec:
containers:
- command:
- kube-apiserver
- --tls-cert-file=/etc/kubernetes/pki/apiserver.crt # 服务端证书
- --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
- --client-ca-file=/etc/kubernetes/pki/ca.crt # 客户端 CA 根证书
2. etcd 的 TLS 配置
etcd 存储集群所有敏感数据，必须通过 TLS 保护。
- 服务端证书：etcd 使用证书对外提供加密服务。
- 客户端证书：API Server 需提供有效证书才能访问 etcd。
# etcd 启动参数示例（/etc/kubernetes/manifests/etcd.yaml）
spec:
containers:
- command:
- etcd
- --cert-file=/etc/kubernetes/pki/etcd/server.crt # 服务端证书
- --key-file=/etc/kubernetes/pki/etcd/server.key
- --client-cert-auth=true # 要求客户端证书认证
- --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt # 客户端 CA 根证书
3. kubelet 的 TLS 配置
kubelet 是节点上的代理，需通过 TLS 与 API Server 通信。
- 服务端证书：kubelet 提供 HTTPS 端点供 API Server 访问（如日志、exec 功能）。
- 客户端证书：kubelet 使用证书向 API Server 认证自己。
# kubelet 配置示例（/var/lib/kubelet/config.yaml）
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
serverTLSBootstrap: true # 自动生成服务端证书
clientCAFile: /etc/kubernetes/pki/ca.crt
4. Ingress 的 TLS 配置
通过 Ingress 暴露的 HTTPS 服务需配置 TLS 证书。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
tls:
- hosts:
- api.example.com
secretName: tls-secret # 引用存储证书的 Secret
rules:
- host: api.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: gateway-service
port:
number: 80
4. 证书管理
Kubernetes 依赖证书颁发机构（CA）体系管理证书：
- 根证书（CA）：集群信任的根证书（如
/etc/kubernetes/pki/ca.crt）。 - 自动轮换：kubelet 支持自动轮换证书（通过
RotateKubeletServerCertificate特性）。 - 工具支持：
kubeadm：自动生成集群证书。cert-manager：自动化管理 Ingress 证书（如 Let’s Encrypt）。
为什么必须使用 TLS？
- 默认安全要求：Kubernetes 设计时即要求所有生产环境通信必须加密。
- 合规性：满足 GDPR、HIPAA 等数据安全法规。
- 防御攻击：
- 防止集群内部流量被监听（如同一 VPC 内的其他服务）。
- 防止 API Server 被未授权访问（如公网暴露的集群）。
- 零信任架构：默认不信任任何组件，所有通信需验证身份。
总结
Kubernetes 使用 TLS 是构建安全集群的基石，涵盖加密、认证和完整性三大核心安全需求。无论是集群内部组件通信，还是对外暴露服务，TLS 都是防止数据泄露和未授权访问的关键防线。
扫一扫
1125
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
