壹、k8s Ingress 样例大全

以下为 Kubernetes Ingress 的典型配置样例大全，涵盖常见生产场景，结合最佳实践和关键注释说明，便于直接复用或调整：

---

🔧 一、基础路由与 TLS 终止

场景：将不同路径的 HTTP/HTTPS 流量路由到后端服务，并启用 TLS 加密。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: basic-ingress
spec:tls:                            # TLS 配置部分- hosts:- example.comsecretName: example-tls-secret  # 证书需提前存入 Secretrules:- host: example.com              # 域名匹配http:paths:- path: /app1                # 路径匹配pathType: Prefixbackend:service:name: app1-service      # 后端服务名port: number: 80- path: /app2pathType: Prefixbackend:service:name: app2-serviceport: number: 8080

关键点：

• tls.secretName 需提前通过 kubectl create secret tls 创建证书
• 若无域名可省略 host 字段，匹配所有域名请求

---

🔄 二、高级路由控制

1. URL 重写（适用后端服务路径与入口路径不一致）

metadata:annotations:nginx.ingress.kubernetes.io/rewrite-target: /$1  # 重写路径
spec:rules:- host: go-app.example.comhttp:paths:- path: /api(/|$)(.*)       # 捕获路径参数pathType: Prefixbackend:service:name: go-serviceport: number: 80

效果：
请求 go-app.example.com/api/user → 后端实际接收路径 /user

---

2. 多路径路由到不同服务

spec:rules:- host: foo.bar.comhttp:paths:- path: "/foo"backend:serviceName: service-foo  # 服务1servicePort: 80- path: "/bar"backend:serviceName: service-bar  # 服务2servicePort: 80

适用场景：
微服务架构按功能拆分路径

---

🚦 三、流量治理策略

1. 金丝雀发布（灰度发布）

metadata:annotations:nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-weight: "15"  # 15%流量到新版本
spec:rules:- host: canary.example.comhttp:paths:- path: /backend:service:name: new-service      # 新版本服务port: 80

说明：
剩余 85% 流量仍走旧服务

---

2. 粘性会话（会话保持）

metadata:annotations:nginx.ingress.kubernetes.io/affinity: "cookie"nginx.ingress.kubernetes.io/session-cookie-name: "user-route"nginx.ingress.kubernetes.io/session-cookie-expires: "172800"  # 有效期2天
spec:rules:- host: shop.example.comhttp:paths:- path: /backend:service:name: cart-serviceport: 80

适用场景：
购物车、用户登录态保持

---

🔐 四、安全增强配置

1. 强制 HTTPS 跳转

metadata:annotations:nginx.ingress.kubernetes.io/force-ssl-redirect: "true"  # HTTP自动跳HTTPS
spec:tls:- hosts:- secure.example.comsecretName: tls-secretrules:- host: secure.example.comhttp:paths:- path: /backend: ...

---

2. 通配符域名证书

spec:tls:- hosts:- "*.example.com"           # 支持所有子域名secretName: wildcard-tls-secretrules:- host: app1.example.com        # 子域名1http: ...- host: app2.example.com        # 子域名2http: ...

注意：
证书需包含通配符 *

---

🌐 五、跨命名空间路由

场景：将流量路由到其他 Namespace 的服务

spec:rules:- host: cross-ns.example.comhttp:paths:- path: /backend:service:name: other-service   port: 80namespace: dev-team  # 指定目标命名空间

权限要求：
Ingress Controller 需有访问目标 Namespace 的权限

---

⚙️ 六、云厂商集成（华为云 CCI 示例）

apiVersion: extensions/v1beta1
kind: Ingress
metadata:annotations:kubernetes.io/elb.id: "2d48d034-..."  # 绑定云 ELB 实例 IDkubernetes.io/elb.port: '6071'         # ELB 监听端口labels:isExternal: "true"                    # 必填标识
spec:rules:- http:paths:- path: /backend:serviceName: nginxservicePort: 8080

适用场景：
公有云托管 Kubernetes 服务

---

💎 总结对比表：按场景选择配置

场景	配置要点	关键注解/字段
基础 HTTPS 路由	TLS 证书 + 路径匹配	tls.secretName, spec.rules.paths
灰度发布	按权重分流流量	canary: "true", canary-weight
会话保持	基于 Cookie 的亲和性	affinity: "cookie", session-cookie-name
跨命名空间访问	指定后端服务 Namespace	backend.service.namespace
云厂商 ELB 集成	绑定云负载均衡器 ID 和端口	kubernetes.io/elb.id, kubernetes.io/elb.port
通配符域名	泛域名证书 + 多 host 规则	tls.hosts: ["*.domain.com"]

💡 调试提示：

• 使用 kubectl describe ingress <name> 查看事件及错误
• 若配置未生效，检查 Ingress Controller 日志（如 kubectl logs -n ingress-nginx <pod>）
• 生产环境推荐托管 Ingress 控制器（如 AWS ALB、GCE L7）降低运维成本

---

贰、k8s Service 样例大全

以下是 Kubernetes Service 四种核心类型（ClusterIP、NodePort、LoadBalancer、ExternalName）的配置样例大全，附带使用场景和关键参数解析：

🔧 一、ClusterIP（默认类型）

场景：集群内服务间通信（东西流量）

apiVersion: v1
kind: Service
metadata:name: redis-service  # 集群内访问地址：redis-service:6379
spec:type: ClusterIP      # 可省略（默认类型）selector:app: redis         # 关联标签为 app=redis 的 Podports:- name: tcp-port   # 端口命名（可选）protocol: TCPport: 6379       # Service 暴露的端口targetPort: 6379 # Pod 监听端口

特点：

• 分配一个集群内部虚拟 IP（如 10.96.0.1）
• 仅限集群内访问，无法从外部直接连接
• 服务发现：通过 DNS 名称 <service-name>.<namespace>.svc.cluster.local

---

🌐 二、NodePort

场景：通过节点 IP 暴露服务（开发测试常用）

apiVersion: v1
kind: Service
metadata:name: web-nodeport
spec:type: NodePortselector:app: nginxports:- port: 80          # Service 端口（集群内访问）targetPort: 80     # Pod 端口nodePort: 30080    # 节点开放端口（范围 30000-32767）

访问方式：

• 集群内：web-nodeport:80
• 集群外：<任意节点IP>:30080 → 自动路由到后端 Pod
  注意：生产环境需配合负载均衡器使用

---

☁️ 三、LoadBalancer（云厂商集成）

场景：公有云环境自动创建外部负载均衡器

apiVersion: v1
kind: Service
metadata:name: api-loadbalancerannotations:service.beta.kubernetes.io/aws-load-balancer-type: "nlb" # AWS NLB 注解
spec:type: LoadBalancerselector:app: api-serverports:- protocol: TCPport: 443         # LB 监听端口targetPort: 8080   # Pod 端口externalTrafficPolicy: Local # 保留客户端真实 IP

云厂商行为：

• AWS → 创建 NLB/ALB
• GCP → 创建 Network LB
• Azure → 创建 Azure LB
  访问方式：
• 通过云厂商分配的 LB 公网 IP 访问（如 https://<LB-IP>:443）

---

🔗 四、ExternalName（CNAME 代理）

场景：将服务映射到外部 DNS 名称（如云数据库）

apiVersion: v1
kind: Service
metadata:name: mysql-external
spec:type: ExternalNameexternalName: mysql.prod.example.com  # 外部服务地址

访问方式：

• 集群内访问 mysql-external → 自动解析为 mysql.prod.example.com
  典型用途：
• 代理 RDS、ElastiCache 等托管服务
• 简化迁移（无需修改应用配置）

---

⚙️ 高级配置样例

1. 多端口 Service（如 Web + Metrics）

apiVersion: v1
kind: Service
metadata:name: multi-port-svc
spec:type: ClusterIPselector:app: monitoringports:- name: httpport: 80targetPort: 8080- name: metricsport: 9100targetPort: 9100

2. 会话保持（Session Affinity）

spec:type: NodePortsessionAffinity: ClientIP  # 基于客户端 IP 会话保持sessionAffinityConfig:clientIP:timeoutSeconds: 3600   # 会话保持超时

3. 指定静态 ClusterIP

spec:type: ClusterIPclusterIP: 10.96.0.100     # 手动指定固定 IP

---

💎 四类 Service 核心对比

类型	访问范围	典型场景	网络层	外部依赖
ClusterIP	集群内部	微服务间通信	L4	无
NodePort	节点IP + 端口	开发测试、临时暴露	L4	节点网络可达
LoadBalancer	云厂商 LB 公网 IP	生产环境对外暴露	L4	云厂商 LB 服务
ExternalName	集群内部	代理外部服务（如 RDS）	L7 (DNS)	外部 DNS 解析

---

🔧 调试命令

# 查看 Service 详情
kubectl describe svc <service-name># 检查 Endpoints 是否正常
kubectl get endpoints <service-name># 集群内访问测试
kubectl run curl --image=curlimages/curl -it --rm -- \curl http://<service-name>:<port>

💡 生产建议：

• 优先使用 Ingress + ClusterIP 管理 HTTP 流量（L7 路由）
• LoadBalancer 用于 TCP/UDP 服务（如数据库）
• 避免直接用 NodePort 暴露生产服务（安全风险高）