k8s Ingress、Service配置各样例大全

原创已于 2025-06-23 10:28:38 修改 · 1k 阅读

16 ·

CC 4.0 BY-SA版权

文章标签：

#云原生 #kubernetes #容器

于 2025-06-23 09:43:20 首次发布

云原生专栏收录该内容

7 篇文章

订阅专栏

壹、k8s Ingress 样例大全

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

🔧 一、基础路由与 TLS 终止

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: basic-ingress
spec:
  tls:                            # TLS 配置部分
  - hosts:
      - example.com
    secretName: example-tls-secret  # 证书需提前存入 Secret
  rules:
  - host: example.com              # 域名匹配
    http:
      paths:
      - path: /app1                # 路径匹配
        pathType: Prefix
        backend:
          service:
            name: app1-service      # 后端服务名
            port: 
              number: 80
      - path: /app2
        pathType: Prefix
        backend:
          service:
            name: app2-service
            port: 
              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.com
    http:
      paths:
      - path: /api(/|$)(.*)       # 捕获路径参数
        pathType: Prefix
        backend:
          service:
            name: go-service
            port: 
              number: 80

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

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

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

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

🚦 三、流量治理策略

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

metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "15"  # 15%流量到新版本
spec:
  rules:
  - host: canary.example.com
    http:
      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.com
    http:
      paths:
      - path: /
        backend:
          service:
            name: cart-service
            port: 80

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

🔐 四、安全增强配置

1. 强制 HTTPS 跳转

metadata:
  annotations:
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"  # HTTP自动跳HTTPS
spec:
  tls:
  - hosts:
      - secure.example.com
    secretName: tls-secret
  rules:
  - host: secure.example.com
    http:
      paths:
      - path: /
        backend: ...

2. 通配符域名证书

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

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

🌐 五、跨命名空间路由

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

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

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

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

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/elb.id: "2d48d034-..."  # 绑定云 ELB 实例 ID
    kubernetes.io/elb.port: '6071'         # ELB 监听端口
  labels:
    isExternal: "true"                    # 必填标识
spec:
  rules:
  - http:
      paths:
      - path: /
        backend:
          serviceName: nginx
          servicePort: 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 的 Pod
  ports:
    - name: tcp-port   # 端口命名（可选）
      protocol: TCP
      port: 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: NodePort
  selector:
    app: nginx
  ports:
    - port: 80          # Service 端口（集群内访问）
      targetPort: 80     # Pod 端口
      nodePort: 30080    # 节点开放端口（范围 30000-32767）

访问方式：

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

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

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

apiVersion: v1
kind: Service
metadata:
  name: api-loadbalancer
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb" # AWS NLB 注解
spec:
  type: LoadBalancer
  selector:
    app: api-server
  ports:
    - protocol: TCP
      port: 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: ExternalName
  externalName: 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: ClusterIP
  selector:
    app: monitoring
  ports:
    - name: http
      port: 80
      targetPort: 8080
    - name: metrics
      port: 9100
      targetPort: 9100

2. 会话保持（Session Affinity）

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

3. 指定静态 ClusterIP

spec:
  type: ClusterIP
  clusterIP: 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 暴露生产服务（安全风险高）

11 条评论

小马过河R 2025.06.25
consul是google开源的一个使用go语言开发的服务发现、配置管理中心服务。内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如ZooKeeper等）。服务部署简单，只有一个可运行的二进制的包。每个节点都需要运行agent，他有两种运行模式server和client。每个数据中心官方建议需要3或5个server节点以保证数据安全，同时保证server-leader的选举能够正确的进行。

小马过河R 2025.06.25
Nacos（Dynamic Naming and Configuration Service）是阿里巴巴开源的一款动态服务发现、配置管理和服务管理平台，旨在简化云原生应用和微服务架构中的服务治理工作‌。其核心功能包括服务注册与发现、动态配置管理、健康监测及流量控制，支持高可用分布式架构与多语言生态集成，广泛应用于电商、金融等领域。‌‌

小马过河R 2025.06.25
在Kubernetes中通过ConfigMapKeyRef注入的环境变量，程序代码按照常规取环境变量的方法或函数可取

小马过河R 2025.06.24
流水线系统的组成：源代码管理：如Git，用于版本控制。自动构建工具：如Jenkins, GitLab CI, CircleCI等，用于自动化构建过程。自动测试工具：用于执行自动化测试，包括单元测试、集成测试等。部署工具：如Ansible, Docker, Kubernetes等，用于自动化部署过程。监控和报告工具：用于监控应用的性能和健康状况，提供反馈。
- 小马过河R回复小马过河R 2025.06.24
  流水线就是将那些基础部署动作串起来组合运行，实现自动CICD的整个过程。

小马过河R 2025.06.24
在软件开发中，流水线系统（通常被称为CI/CD流水线或部署流水线）是一种自动化的过程，用以快速、可靠地将软件从开发阶段引向生产阶段。CI代表持续集成（Continuous Integration），而CD代表持续交付（Continuous Delivery）或持续部署（Continuous Deployment）。这个系统主要帮助软件开发团队高效地完成代码的编写、测试、部署等一系列过程。

小马过河R 2025.06.23
annotations: networke.myxxx/lbids: 'aaa-bbb,ccc-ddd' 这里可以是自己的插件
- 小马过河R回复小马过河R 2025.09.03
  即文中并未明确说明 ingress 的apiVersion 可以是原生或插件或CRD等来支持路由
- 小马过河R回复小马过河R 2025.09.03
  需注意这里上级的apiVersion 是networke.myxxx，它自定义的v1接口地址，kind=ingress。而这个apiVersion 是通过CRD事先配置好的才能支持 LB。
- 小马过河R回复小马过河R 2025.09.03
  这里还需要注意，apiVersion: networke.myxxx.com/v1 kind: Ingress 这里的apiVersion 接口有可能是自定义的CRD才行来配合networke.myxxx/lbids 配置的LB的生效。也就是CRD配置的apiVersion 是apiVersion: networke.myxxx.com/v1 且它的kind是kind: Ingress listKind: IngressList plural: ingresses

小马过河R 2025.06.23
一、Helm简介 ‌定义‌：Helm是官方提供的类似于YUM的包管理器，用于Kubernetes应用的部署环境流程封装。 ‌目的‌：使Kubernetes的应用管理（如Deployment、Service等）可配置，通过动态生成Kubernetes资源清单文件，并调用Kubectl自动执行资源部署。 ‌优势‌：简化了Kubernetes应用的部署和管理，特别是微服务化应用的容器部署。二、Helm核心概念 ‌Chart（软件包）‌ 定义：Helm的软件包，采用TAR格式，包含一组定义Kubernetes资源的YAML文件。类似：APT的DEB包或YUM的RPM包。 ‌Repository（仓库）‌ 定义：Helm的软件仓库，本质上是一个保存Chart软件包供用户下载的Web服务器，并提供Chart包清单文件以供查询。功能：Helm可管理多个不同的Repository。 ‌Release（实例）‌ 定义：使用helm install命令在Kubernetes集群中部署的Chart称为Release。理解：可视为使用Chart包部署的一个应用实例，一个Chart可在同一集群中多次安装，每次安装创建一个新的Release。