HELM - Kubernetes 中的类YUM 工具

一、HELM概念

1、什么是HELM

2、HELM重要概念

3、组件结构

4、历史版本

二、HELM安装和演示

1、安装初始化

下载/上传包

$ curl -fsSL -o get_helm.sh
https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh

解压，移动，加执行权限，版本查看

tar -zxvf helm-v3.12.3-linux-amd64.tar.gz
cp -a linux-amd64/helm /usr/local/bin/
chmod a+x /usr/local/bin/helm
helm version

清除垃圾文件，rm -rf helm-v3.12.3-linux-amd64.tar.gz linux-amd64/

初始化

指定仓库和地址，查看仓库和地址，查看chart包

helm repo add bitnami https://charts.bitnami.com/bitnami
//建议添加阿里云的地址
helm repo add bitnami https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
helm repo ls
helm search repo bitnami

安装chart

更新仓库和索引、查看修改可选项，安装

helm repo update              # 确定我们可以拿到最新的 charts 列表
helm show values bitnami/aerospike
helm install bitnami/xxx --generate-name  #随机生成名字

helm show chart bitnami/mysql   # chart 的基本信息
helm show all bitnami/mysq   # chart 的所有信息
helm uninstall m名字   #删除
$ helm uninstall apache-1612624192 # 该命令会从Kubernetes卸载 mysql1612624192，
它将删除和该版本相关的所有相关资源（service、deployment、 pod等等）甚至版本历
史
 --keep-history # 选项， Helm 将会保存版本历史
$ helm status apache-1612624192 # 查看该版本的信息

三大概念

Chart 代表着 Helm 包。它包含在 Kubernetes 集群内部运行应用程序，工具或服务所需的所有资源定 义。你可以把它看作是 Homebrew formula，Apt dpkg，或 Yum RPM 在Kubernetes 中的等价物

'helm search'：查找 Charts

# 用于在 Helm Hub（https://hub.helm.sh）上搜索 Helm charts
$ helm search hub wordpress
# 用于在配置的 Helm 仓库中搜索 Helm charts，~/.config/helm/repositories.yaml 中被定义
持久化
helm search repo wordpress
# Helm 搜索使用模糊字符串匹配算法，所以你可以只输入名字的一部分

安装前自定义 chart

$ helm show values bitnami/apache # 查看 chart 中的可配置选项
# 使用 YAML 格式的文件覆盖上述任意配置项，并在安装过程中使用该文件
$ vi values.yaml   //写不一样的地方
service:
 type: NodePort
$ helm install -f values.yaml bitnami/apache --generate-name

安装过程中有两种方式传递配置数据

        --values (或 -f )：使用 YAML 文件覆盖配置。可以指定多次，优先使用最右边的文件

         --set ：通过命令行的方式对指定项进行覆盖

         如果同时使用两种方式，则 --set 中的值会被合并到 --values 中，但是 --set 中的值优先级更高。 在 --set 中覆盖的内容会被被保存在 ConfigMap 中。可以通过 helm get values -name> 来 查看指定 release 中 --set 设置的值。也可以通过运行 helm upgrade 并指定 --reset-values 字段来 清除 --set 中设置的值

--set 的格式和限制

--set 选项使用0或多个 name/value 对。最简单的用法类似于： --set name=value ，等价于如下 YAML 格式：  

name: value

多个值使用逗号分割，因此 --set a=b,c=d 的 YAML 表示是：  

a: b
c: d

支持更复杂的表达式。例如， --set outer.inner=value 被转换成了：  

outer:
 inner: value

列表使用花括号（ {} ）来表示。例如， --set name={a, b, c} 被转换成了：  

name:
 - a
 - b
 - c

某些 name/key 可以设置为 null 或者空数组，例如 --set name=[],a=null

name: []
a: null

  从 2.5.0 版本开始，可以使用数组下标的语法来访问列表中的元素。例如 --set servers[0].port=80 就变成了：

servers:
 - port: 80

多个值也可以通过这种方式来设置。 --set servers[0].port=80,servers[0].host=example 变成 了：  

servers:
 - port: 80
   host: example

如果需要在 --set 中使用特殊字符，你可以使用反斜线来进行转义；

name: "value1,value2"

--set name=value1\,value2 就 变成了： --set nodeSelector."kubernetes.io/role"=master

nodeSelector:
 kubernetes.io/role: master

更多安装方法

helm install 命令可以从多个来源进行安装：
    chart 的仓库（如上所述）
    本地 chart 压缩包（ helm install foo foo-0.1.1.tgz ）
    解压后的 chart 目录（ helm install foo path/to/foo ）
    完整的 URL（ helm install foo https://example.com/charts/foo-1.2.3.tgz ）

升级 release 和失败时恢复

安装、升级、回滚时的有用选项

helm uninstall'：卸载 release

'helm repo'：使用仓库

2、创建一个自己的 Chart

创建模版

helm create myapp

（基本配置、charts包、资源清单文件、可以改变的选项）

删除不必要的文件，rm -rf values.yaml templates/

vi templates/nodePort.yaml

apiVersion: v1
kind: Service
metadata:
  labels:
    app: myapp-test
  name: myapp-test-202401110926-svc
spec:
  ports:
  - name: 80-80
    port: 80
    protocol: TCP
    targetPort: 80
    nodePort: 31111
  selector:
    app: myapp-test
  type: NodePort

vi templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: myapp-test
  name: myapp-test-202401110926-deploy
spec:
  replicas: 5
  selector:
    matchLabels:
      app: myapp-test
  template:
    metadata:
      labels:
        app: myapp-test
    spec:
      containers:
      - image: wangyanglinux/myapp:v1.0
        name: myapp

 安装，helm install myapp myapp/

注入灵魂

templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: myapp-test
  name: myapp-test-{{ now | date "20060102030405" }}-deploy
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: myapp-test
  template:
    metadata:
      labels:
        app: myapp-test
    spec:
      containers:
      - image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
        name: myapp

templates/service.yaml

apiVersion: v1
kind: Service
metadata:
  labels:
    app: myapp-test
  name: myapp-test-{{ now | date "20060102030405" }}-svc
spec:
  ports:
  - name: 80-80
    port: 80
    protocol: TCP
    targetPort: 80
    {{- if eq .Values.service.type "NodePort" }}
    nodePort: {{.Values.service.nodeport }}
    {{- end }}
  selector:
    app: myapp-test
  type: {{ .Values.service.type | quote }}

myapp/values.yaml（添加自己需要修改的）

# myapp 的默认值
# 这是一个 YAML 格式的文件
# 声明要传递到模板中的变量
replicaCount: 5
image:
  repository: wangyanglinux/myapp
  tag: "v1.0"
service:
  type: NodePort
  nodeport: 32321

三、Ingress - nginx

1、四层负载和七层负载

四层，是http都得是

七层，两次握手

2、基于Ingress的七层负载

3、流量分析

4、部署Ingress

架构图

 部署

上传镜像

解压、unzip ingress-nginx.zip 

导入镜像

导入到每个节点，节点上传镜像

去主节点，/root/10/4/2、ingress-nginx/chart，解压文件

自改配置文件

安装

kubectl create namespace ingress
helm install ingress-nginx -n ingress . -f values.yaml

实验1

apiVersion: v1
kind: Service
metadata:
  name: ingress-httpproxy-www1
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    hostname: www1
  type: ClusterIP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-httpproxy-www1
spec:
  ingressClassName: nginx
  rules:
  - host: www1.xinxianghf.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: ingress-httpproxy-www1
            port:
              number: 80

添加win域名

实验二

1. TLS 证书生成与 Secret 创建（前置操作）

HTTPS 代理需先通过 OpenSSL 生成自签名证书，再创建 Kubernetes Secret 存储证书（文档中已提及关键命令，此处补充完整流程）。

1.1 生成 TLS 证书

执行以下命令生成tls.crt（证书）和tls.key（私钥）：

bash

# 生成自签名证书，有效期365天，CN（通用名）设为目标域名ssl.xinxianghf.com
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=ssl.xinxianghf.com/O=nginxsvc"

1.2 创建 Kubernetes Secret

将证书存储为 Secret（Ingress 需引用此 Secret 实现 HTTPS）：

bash

kubectl create secret tls ssl-nginx-secret \
  --cert=tls.crt \
  --key=tls.key \
  -n default  # 与Ingress同命名空间（文档中Ingress在default命名空间）

2. Deployment 资源清单（名称：ingress-httpproxy-ssl）

用于部署后端业务 Pod，标签hostname: ssl需与 Service 的选择器匹配，文档中缺失镜像、端口等关键字段，此处按常规 Nginx 应用补全。

yaml

apiVersion: apps/v1  # Deployment资源的API版本（K8s v1.9+固定为apps/v1）
kind: Deployment
metadata:
  name: ingress-httpproxy-ssl  # Deployment名称，与业务标识一致
  namespace: default  # 与Service、Ingress同命名空间
spec:
  replicas: 2  # 副本数，按业务需求调整（文档中缺失，此处设为2）
  selector:
    matchLabels:
      hostname: ssl  # 标签选择器，匹配Pod模板标签
  template:
    metadata:
      labels:
        hostname: ssl  # Pod标签，需与Service选择器一致
    spec:
      containers:
      - name: nginx  # 容器名称
        image: nginx:1.25  # 容器镜像（文档中缺失，选用稳定版Nginx）
        ports:
        - containerPort: 80  # 容器暴露端口（与Service的targetPort对应）
        resources:  # 资源限制（可选，避免资源耗尽）
          limits:
            cpu: "500m"
            memory: "512Mi"
          requests:
            cpu: "200m"
            memory: "256Mi"

3. Service 资源清单（名称：ingress-httpproxy-ssl）

用于暴露 Deployment 管理的 Pod，为 Ingress 提供后端服务地址，文档中配置完整，仅补充命名空间字段。

yaml

apiVersion: v1  # Service资源的API版本（固定为v1）
kind: Service
metadata:
  name: ingress-httpproxy-ssl  # Service名称，需与Ingress后端配置一致
  namespace: default  # 与Deployment、Ingress同命名空间
spec:
  ports:
  - port: 80  # Service对外暴露端口
    targetPort: 80  # 转发到Pod的端口（与容器的containerPort一致）
    protocol: TCP  # 协议类型（默认TCP，显式声明更清晰）
  selector:
    hostname: ssl  # 标签选择器，匹配Deployment创建的Pod
  type: ClusterIP  # 服务类型（默认，仅集群内部可访问，Ingress依赖此类型）

4. Ingress 资源清单（名称：ingress-httpproxy-ssl）

核心配置，实现 HTTPS 路由与 SSL 重定向（HTTP 自动跳转 HTTPS），文档中缺失path、pathType、secretName等字段，此处补全并对齐 Secret 配置。

yaml

apiVersion: networking.k8s.io/v1  # Ingress稳定API版本（K8s v1.19+）
kind: Ingress
metadata:
  name: ingress-httpproxy-ssl  # Ingress名称，与业务标识一致
  namespace: default  # 与其他资源同命名空间
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"  # 强制HTTP跳转HTTPS
spec:
  ingressClassName: nginx  # 指定使用Nginx Ingress控制器（需提前部署）
  tls:  # HTTPS配置，引用前面创建的Secret
  - hosts:
    - ssl.xinxianghf.com  # 需与证书CN（通用名）一致
    secretName: ssl-nginx-secret  # 引用存储TLS证书的Secret名称
  rules:  # 路由规则，匹配域名ssl.xinxianghf.com
  - host: ssl.xinxianghf.com
    http:
      paths:
      - path: /  # 匹配根路径及所有子路径
        pathType: Prefix  # 路径匹配类型（Prefix=前缀匹配）
        backend:
          service:
            name: ingress-httpproxy-ssl  # 转发到目标Service名称
            port:
              number: 80  # 转发到Service的80端口

部署与验证命令

  1. 批量部署资源：将上述 3 类资源清单保存为ingress-https-all.yaml，执行部署：

    bash

    kubectl apply -f ingress-https-all.yaml

  2. 验证资源状态：

    bash

    # 查看Deployment、Service、Ingress状态
kubectl get deploy,svc,ing -n default | grep ingress-httpproxy-ssl
# 查看Secret是否存在
kubectl get secret ssl-nginx-secret -n default

  3. 测试 HTTPS 访问：在集群外部，通过curl或浏览器访问https://ssl.xinxianghf.com（需确保域名已解析到 Ingress 控制器 IP）。

实验三

Kubernetes Ingress-nginx BasicAuth 代理资源清单与部署指南

基于文档中 Ingress BasicAuth 代理的核心配置，补充完整依赖步骤（认证文件创建、Secret 生成）及资源清单，确保 HTTP 基础认证功能可正常使用。

一、前置操作：创建 BasicAuth 认证文件与 Secret

BasicAuth 依赖 htpasswd 工具生成加密认证文件，再通过 Kubernetes Secret 存储，供 Ingress 调用。

1. 安装 htpasswd 工具

文档提及 dnf 包管理命令，需先安装生成认证文件的依赖工具（httpd-tools 包含 htpasswd）：

# 基于 RHEL/CentOS 系统（文档中 dnf 命令适配此系统）
dnf -y install httpd-tools

2. 生成 BasicAuth 认证文件

创建包含用户名和加密密码的认证文件（示例用户名为 admin，可自定义）：

bash

# 生成 .htpasswd 文件，-c 表示创建新文件，admin 为用户名（执行后需输入两次密码）
htpasswd -c .htpasswd admin
# （可选）添加更多用户（无需 -c，避免覆盖现有文件）
# htpasswd .htpasswd user2

3. 创建存储认证信息的 Secret

将 .htpasswd 文件转为 Kubernetes Secret（Ingress 需通过此 Secret 验证身份）：

bash

kubectl create secret generic basicauth-secret \
  --from-file=.htpasswd \
  -n default  # 与后续 Ingress 同命名空间，可按需修改

二、Ingress 资源清单（BasicAuth 核心配置）

文档中 Ingress 缺失 apiVersion、完整 annotations、path 等关键字段，此处补全并对齐 BasicAuth 认证逻辑，实现访问目标域名时触发账号密码验证。

yaml

apiVersion: networking.k8s.io/v1  # Ingress 稳定 API 版本（K8s v1.19+ 适用）
kind: Ingress
metadata:
  name: ingress-basicauth-proxy  # Ingress 名称，自定义标识
  namespace: default  # 与 Secret 同命名空间
  annotations:
    # 启用 BasicAuth 认证类型
    nginx.ingress.kubernetes.io/auth-type: basic
    # 引用存储认证信息的 Secret（需与步骤 3 中 Secret 名称一致）
    nginx.ingress.kubernetes.io/auth-secret: basicauth-secret
    # 认证弹窗提示信息（自定义，告知用户需输入账号密码）
    nginx.ingress.kubernetes.io/auth-realm: '请输入 BasicAuth 认证账号密码（来自薪享宏福环境）'
spec:
  ingressClassName: nginx  # 指定使用 Nginx Ingress 控制器（需提前部署）
  rules:
  - host: auth.xinxianghf.com  # 需认证的目标域名（文档隐含业务域名，自定义）
    http:
      paths:
      - path: /  # 匹配根路径及所有子路径（所有访问该域名的请求均需认证）
        pathType: Prefix  # 路径匹配类型：前缀匹配
        backend:
          service:
            name: target-service  # 转发目标 Service 名称（需替换为实际业务 Service）
            port:
              number: 80  # 目标 Service 的端口（需与业务 Service 端口一致）

三、配套资源说明（可选，确保完整链路）

若目标业务尚未部署 Service，需补充 Service 资源（需与 Ingress 中 target-service 对应），示例如下：

yaml

apiVersion: v1
kind: Service
metadata:
  name: target-service  # 与 Ingress 后端 Service 名称一致
  namespace: default
spec:
  ports:
  - port: 80
    targetPort: 80  # 后端 Pod 暴露的端口
    protocol: TCP
  selector:
    app: target-app  # 匹配后端业务 Pod 的标签（需与 Deployment 标签一致）
  type: ClusterIP

四、部署与验证步骤

1. 部署资源

bash

# 1. 部署 Secret（已在步骤 3 完成）
# 2. 部署 Service（若需）
kubectl apply -f service.yaml
# 3. 部署 Ingress
kubectl apply -f ingress-basicauth.yaml

2. 验证配置

bash

# 1. 检查 Secret 是否存在
kubectl get secret basicauth-secret -n default
# 2. 检查 Ingress 是否正常
kubectl get ingress ingress-basicauth-proxy -n default
# 3. 测试 BasicAuth 认证（通过 curl 或浏览器访问）
# curl 测试（需输入账号密码，示例用户 admin）
curl -u admin:your_password https://auth.xinxianghf.com
# 或直接在浏览器访问域名，会弹出账号密码输入弹窗

关键说明

  1. 认证安全性：BasicAuth 密码通过 htpasswd 加密存储（默认 SHA-1 加密），但传输过程需搭配 HTTPS（可参考前文 HTTPS 配置），避免密码明文泄露。

  2. 用户管理：如需修改 / 删除用户，直接编辑 .htpasswd 文件后，重新创建 Secret（需先删除旧 Secret）：

    bash

    kubectl delete secret basicauth-secret -n default
kubectl create secret generic basicauth-secret --from-file=.htpasswd -n default

  3. 控制器依赖：需确保集群已部署 Nginx Ingress 控制器，否则 Ingress 配置无法生效（可通过 helm list -n ingress-nginx 检查控制器部署状态）。

实验四

Kubernetes Ingress-nginx 域名重定向资源清单与部署指南

基于文档中域名重定向的核心需求，补充完整的 Ingress 配置（含关键注解、重定向规则），确保实现 redirect.xinxianghf.com 域名的定向转发功能，同时适配 Nginx Ingress 控制器特性。

一、Ingress 域名重定向资源清单（核心配置）

文档中 Ingress 缺失重定向注解、路径规则等关键字段，此处补全两种常见重定向场景（按需选择），均基于 Nginx Ingress 官方注解实现。

场景 1：重定向到指定域名（例如 www.xinxianghf.com）

适用于将 redirect.xinxianghf.com 的所有请求，统一转发到目标域名（支持 HTTP/HTTPS 跳转）：

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-domain-redirect  # Ingress 名称，自定义标识
  namespace: default  # 与目标服务同命名空间（文档默认 default）
  annotations:
    # 核心：配置重定向目标域名（需替换为实际目标域名）
    nginx.ingress.kubernetes.io/redirect-to: "https://www.xinxianghf.com"
    # 可选：设置重定向状态码（301=永久重定向，302=临时重定向，默认302）
    nginx.ingress.kubernetes.io/redirect-status-code: "301"
spec:
  ingressClassName: nginx  # 指定 Nginx Ingress 控制器（文档明确配置）
  rules:
  - host: redirect.xinxianghf.com  # 需要被重定向的源域名（文档核心域名）
    http:
      paths:
      - path: /  # 匹配源域名的所有路径（/ 表示根路径及所有子路径）
        pathType: Prefix  # 路径匹配类型：前缀匹配（覆盖所有子路径）
        backend:
          # 重定向场景下，后端服务仅需“占位”（实际请求会被注解拦截转发）
          service:
            name: placeholder-service  # 可使用集群内任意存在的 Service（或自定义空 Service）
            port:
              number: 80

场景 2：重定向到带路径的目标地址（例如 www.xinxianghf.com/foo）

适用于需要指定目标路径的场景（例如源域名请求需转发到目标域名的特定页面）：

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-domain-path-redirect  # Ingress 名称，自定义标识
  namespace: default
  annotations:
    # 核心：配置重定向目标（域名+路径）
    nginx.ingress.kubernetes.io/rewrite-target: "https://www.xinxianghf.com/foo$request_uri"
    # 可选：保留源请求的查询参数（例如 ?id=1 会携带到目标地址）
    nginx.ingress.kubernetes.io/preserve-query-params: "true"
    # 可选：重定向状态码（301/302，默认302）
    nginx.ingress.kubernetes.io/redirect-status-code: "302"
spec:
  ingressClassName: nginx
  rules:
  - host: redirect.xinxianghf.com  # 源域名
    http:
      paths:
      - path: /  # 匹配源域名所有路径
        pathType: Prefix
        backend:
          service:
            name: placeholder-service  # 占位 Service（同上）
            port:
              number: 80

二、配套说明：占位 Service 创建（可选）

若集群内无合适的 “占位 Service”，可创建一个空 Service（仅用于满足 Ingress 后端配置格式，不实际处理流量）：

yaml

apiVersion: v1
kind: Service
metadata:
  name: placeholder-service  # 与 Ingress 中 backend.service.name 一致
  namespace: default
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: non-existent-app  # 故意设置不存在的标签（确保无实际 Pod 匹配，仅占位）
  type: ClusterIP

三、部署与验证步骤

1. 部署资源

bash

# 1. （可选）部署占位 Service（若需）
kubectl apply -f placeholder-service.yaml
# 2. 部署 Ingress 重定向配置（选择场景1或场景2的 YAML 文件）
kubectl apply -f ingress-domain-redirect.yaml

2. 验证部署状态

bash

# 查看 Ingress 是否正常创建
kubectl get ingress ingress-domain-redirect -n default
# 查看 Ingress 详细配置（确认注解和规则是否生效）
kubectl describe ingress ingress-domain-redirect -n default

3. 测试重定向功能

通过 curl 测试源域名是否能正确跳转：

bash

# 测试场景1（重定向到 www.xinxianghf.com）
curl -I http://redirect.xinxianghf.com  # -I 仅查看响应头，不获取内容
# 预期响应：Location: https://www.xinxianghf.com（状态码 301/302）
# 测试场景2（重定向到 www.xinxianghf.com/foo）
curl -I http://redirect.xinxianghf.com/bar  # 源路径为 /bar
# 预期响应：Location: https://www.xinxianghf.com/foo/bar（状态码 301/302）

关键注意事项

  1. 控制器依赖：需确保集群已部署 Nginx Ingress 控制器（可通过 kubectl get pods -n ingress-nginx 检查），否则重定向注解无法生效。

  2. HTTPS 适配：若目标域名为 HTTPS，需确保目标域名已配置对应的 TLS 证书（可参考前文 HTTPS 配置方案），避免跳转后出现证书错误。

  3. 状态码选择：

    • 301 永久重定向：适用于域名迁移等长期场景（浏览器会缓存跳转规则）。

    • 302 临时重定向：适用于临时维护、活动跳转等短期场景（浏览器不缓存）。

  4. 路径匹配：path: / + pathType: Prefix 会覆盖源域名的所有子路径（例如 /a、/b/c），若需仅重定向特定路径，可修改 path（例如 path: /old 仅重定向 /old 相关路径）。

实验五

Kubernetes Ingress-nginx 路径重写资源清单与部署指南

基于文档中 Ingress-nginx 重写的核心需求，补充完整配置（含关键注解、路径规则、后端服务关联），实现请求路径的灵活重写与转发，适配常见业务场景（如隐藏后端路径、统一入口路由）。

一、核心概念：rewrite-target 注解

文档中提及的 nginx.ingress.kubernetes.io/rewrite-target 是 Nginx Ingress 实现路径重写的核心注解，作用是将匹配的请求路径重写为指定格式后，转发到后端服务。关键变量说明：

  • $request_uri：保留完整原始请求路径（含查询参数，如 /old?foo=bar）。

  • $uri：仅保留原始请求路径（不含查询参数，如 /old）。

  • $1/$2：通过路径正则捕获的分组（适用于精准匹配特定路径片段）。

二、Ingress 路径重写资源清单（按场景分类）

文档中缺失 名称、命名空间、完整路径规则 等字段，以下按 通用场景 和 精准场景 补全配置，确保可直接部署使用。

场景 1：通用路径重写（将 /old/* 重写为 /new/*）

适用于 “统一前缀替换” 场景（如将旧路径 /old 下的所有请求，重写为后端服务的 /new 路径）：

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-rewrite-generic  # Ingress 名称，自定义标识
  namespace: default  # 与后端服务同命名空间（文档默认场景）
  annotations:
    # 核心：将 /old/ 开头的路径重写为 /new/（保留后续路径片段）
    nginx.ingress.kubernetes.io/rewrite-target: /new/$2
    # 可选：保留原始请求的查询参数（如 ?id=1 会携带到后端）
    nginx.ingress.kubernetes.io/preserve-query-params: "true"
spec:
  ingressClassName: nginx  # 指定 Nginx Ingress 控制器（文档隐含配置）
  rules:
  - host: rewrite.xinxianghf.com  # 绑定的域名（自定义，需解析到 Ingress 控制器 IP）
    http:
      paths:
      - path: /old(/|$)(.*)  # 正则匹配：/old 或 /old/xxx（$1 匹配 /，$2 匹配后续路径）
        pathType: Prefix  # 路径匹配类型：前缀匹配（兼容正则表达式）
        backend:
          service:
            name: www1svc  # 后端服务名称（文档明确指定为 www1svc）
            port:
              number: 80  # 后端服务端口（文档明确为 80）

示例转发逻辑：

  • 原始请求：http://rewrite.xinxianghf.com/old/page1 → 重写后：http://www1svc:80/new/page1

  • 原始请求：http://rewrite.xinxianghf.com/old → 重写后：http://www1svc:80/new

场景 2：根路径重写（将 / 重写为 /index）

适用于 “根路径定向” 场景（如访问域名根路径时，自动转发到后端服务的 /index 页面）：

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-rewrite-root
  namespace: default
  annotations:
    # 核心：将根路径 / 重写为 /index（固定路径重写）
    nginx.ingress.kubernetes.io/rewrite-target: /index
spec:
  ingressClassName: nginx
  rules:
  - host: rewrite.xinxianghf.com
    http:
      paths:
      - path: /  # 匹配根路径
        pathType: Prefix
        backend:
          service:
            name: www1svc
            port:
              number: 80

示例转发逻辑：

  • 原始请求：http://rewrite.xinxianghf.com/ → 重写后：http://www1svc:80/index

场景 3：多路径重写（不同路径对应不同后端路径）

适用于 “多路由区分” 场景（如 /api 路径转发到后端 /v1/api，/web 路径转发到后端 /v2/web）：

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-rewrite-multi-path
  namespace: default
  annotations:
    # 无需全局 rewrite-target，在各路径规则中通过正则分组区分
spec:
  ingressClassName: nginx
  rules:
  - host: rewrite.xinxianghf.com
    http:
      paths:
      # 路径1：/api/* → 重写为 /v1/api/*
      - path: /api(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: www1svc
            port:
              number: 80
        pathType: Prefix
        backend:
          service:
            name: www1svc
            port:
              number: 80
      # 路径2：/web/* → 重写为 /v2/web/*
      - path: /web(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: www1svc
            port:
              number: 80

示例转发逻辑：

  • /api/user → /v1/api/user

  • /web/login → /v2/web/login

三、部署与验证步骤

1. 部署资源

将上述场景的 YAML 保存为对应文件（如 ingress-rewrite.yaml），执行部署：

bash

kubectl apply -f ingress-rewrite.yaml

2. 验证配置正确性

bash

# 1. 查看 Ingress 是否正常创建
kubectl get ingress ingress-rewrite-generic -n default
# 2. 查看 Ingress 详细规则（确认注解和路径配置）
kubectl describe ingress ingress-rewrite-generic -n default

3. 测试重写效果

通过 curl 发送请求，验证路径是否正确重写：

bash

# 测试场景1：/old/page1 → /new/page1
curl -v http://rewrite.xinxianghf.com/old/page1
# 预期响应中可看到 “X-Rewrote-Uri: /new/page1”（Nginx 重写标识）

关键注意事项

  1. 正则匹配规则：路径中的正则需符合 Nginx 语法，(/) 用于匹配路径分隔符，(.*) 用于捕获后续路径片段，避免出现 “路径截断” 问题。

  2. 后端服务兼容性：确保后端服务（www1svc）已部署且能处理重写后的路径（如场景 1 中需后端支持 /new 路径的接口）。

  3. 与 HTTPS 结合：若需 HTTPS 访问，可在 Ingress 中添加 tls 配置（参考前文 HTTPS 方案），重写逻辑不受协议影响。

  4. 注解优先级：若同时配置 rewrite-target 和 redirect-to（重定向），redirect-to 优先级更高（先重定向再重写，需根据业务需求选择）。

5、重写和重定向

定制错误后端资源清单与部署指南

基于文档中 “定制错误后端” 的核心需求，补充完整 Deployment（错误页面服务 + 测试服务）、Service 及 Ingress 配置，实现当业务服务返回 4xx/5xx 错误时，自动跳转至自定义错误页面，提升用户体验。

一、核心组件说明

定制错误后端需依赖 4 类资源，各组件作用如下：

二、完整资源清单

1. 错误页面服务：Deployment（errcode）

部署提供自定义错误页面的服务，补全文档中缺失的 replicas、matchLabels、containerPort 等字段：

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: errcode  # 错误页面服务部署名
  labels:
    app: errcode  # 标签，用于关联Service
spec:
  replicas: 2  # 副本数，确保服务高可用（文档缺失，建议设为2）
  selector:
    matchLabels:
      app: errcode  # 匹配Pod标签
  template:
    metadata:
      labels:
        app: errcode  # Pod标签，与selector一致
    spec:
      containers:
      - name: errweb  # 容器名
        image: wangyanglinux/tools:errweb1.0  # 文档指定的错误页面镜像
        ports:
        - containerPort: 80  # 容器暴露端口（错误页面服务默认80端口）
        resources:  # 资源限制，避免资源耗尽（可选）
          limits:
            cpu: "200m"
            memory: "128Mi"
          requests:
            cpu: "100m"
            memory: "64Mi"

2. 错误页面服务：Service（errcode）

暴露错误页面服务，补全文档中缺失的 protocol、targetPort 字段：

yaml

apiVersion: v1
kind: Service
metadata:
  name: errcode  # 服务名，与Deployment对应
  labels:
    app: errcode  # 标签，用于标识服务
spec:
  ports:
  - name: 80-80  # 端口名（自定义，便于识别）
    port: 80  # Service对外暴露端口
    protocol: TCP  # 协议类型（文档缺失，默认TCP）
    targetPort: 80  # 转发到Pod的端口（与Deployment的containerPort一致）
  selector:
    app: errcode  # 匹配错误页面服务的Pod标签
  type: ClusterIP  # 服务类型（仅集群内部访问，Ingress需依赖此类型）

3. 测试业务服务：Deployment（errtest）

部署用于测试的业务服务，文档配置较完整，仅补全 containerPort 字段：

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: errtest  # 测试业务服务部署名
  labels:
    app: errtest  # 标签，用于关联Service
spec:
  replicas: 1  # 副本数（文档明确为1）
  selector:
    matchLabels:
      app: errtest  # 匹配Pod标签
  template:
    metadata:
      labels:
        app: errtest  # Pod标签，与selector一致
    spec:
      containers:
      - name: tools  # 容器名（文档指定）
        image: wangyanglinux/myapp:v1.0  # 文档指定的测试业务镜像
        ports:
        - containerPort: 80  # 容器暴露端口（测试服务默认80端口）

4. 测试业务服务：Service（errtest）

暴露测试业务服务，补全文档中缺失的 protocol、targetPort 字段：

yaml

apiVersion: v1
kind: Service
metadata:
  name: errtest  # 服务名，与Deployment对应
  labels:
    app: errtest  # 标签，用于标识服务
spec:
  ports:
  - name: 80-80  # 端口名（自定义）
    port: 80  # Service对外暴露端口
    protocol: TCP  # 协议类型（文档缺失，默认TCP）
    targetPort: 80  # 转发到Pod的端口（与Deployment的containerPort一致）
  selector:
    app: errtest  # 匹配测试业务服务的Pod标签
  type: ClusterIP  # 服务类型（仅集群内部访问）

5. Ingress 配置：关联业务与错误后端

核心配置，通过注解指定 “错误后端服务” 及 “触发错误的状态码”，补全文档中缺失的 name、namespace、annotations、host、path 等字段：

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-errbackend  # Ingress名，自定义标识
  namespace: default  # 与上述服务同命名空间（文档默认场景）
  annotations:
    # 核心1：指定错误后端服务（格式：命名空间/服务名:端口）
    nginx.ingress.kubernetes.io/default-backend: default/errcode:80
    # 核心2：指定触发错误跳转的状态码（4xx=客户端错误，5xx=服务端错误）
    nginx.ingress.kubernetes.io/error-page: "404=default/errcode:80,500=default/errcode:80,503=default/errcode:80"
    # 可选：设置错误页面缓存时间（避免频繁请求错误服务，单位秒）
    nginx.ingress.kubernetes.io/error-page-cache-timeout: "30"
spec:
  ingressClassName: nginx  # 指定Nginx Ingress控制器（文档隐含配置）
  rules:
  - host: errtest.xinxianghf.com  # 绑定的业务域名（自定义，需解析到Ingress控制器IP）
    http:
      paths:
      - path: /  # 匹配业务域名的所有路径
        pathType: Prefix  # 路径匹配类型：前缀匹配
        backend:
          service:
            name: errtest  # 目标业务服务（测试服务errtest）
            port:
              number: 80  # 业务服务端口

三、部署与验证步骤

1. 批量部署资源

将上述 5 类资源清单保存为 ingress-errbackend-all.yaml，执行部署：

bash

kubectl apply -f ingress-errbackend-all.yaml

2. 验证资源状态

bash

# 1. 查看Deployment状态（确保所有Pod都为Running）
kubectl get deploy errcode errtest -n default
# 2. 查看Service状态（确保服务正常暴露）
kubectl get svc errcode errtest -n default
# 3. 查看Ingress状态（确保路由规则生效）
kubectl get ingress ingress-errbackend -n default

3. 测试错误后端效果

通过 curl 模拟错误请求，验证是否跳转至自定义错误页面：

bash

# 测试1：访问不存在的路径（触发404错误）
curl -I http://errtest.xinxianghf.com/nonexistent-path
# 预期响应：状态码 404，且响应内容为 errcode 服务的自定义404页面
# 测试2：模拟服务端错误（若errtest服务支持，可访问触发500的接口）
curl -I http://errtest.xinxianghf.com/500-test
# 预期响应：状态码 500，且响应内容为 errcode 服务的自定义500页面

关键注意事项

  1. 镜像可用性：确保文档指定的镜像（wangyanglinux/tools:errweb1.0、wangyanglinux/myapp:v1.0）能在集群内拉取，若拉取失败，需配置镜像仓库密钥或替换为可访问的镜像。

  2. 错误状态码配置：error-page 注解中可根据业务需求补充更多状态码（如 403、401 等），格式为 “状态码=命名空间/服务名:端口”。

  3. 域名解析：需将 errtest.xinxianghf.com 解析到 Nginx Ingress 控制器的 IP（可通过 kubectl get svc -n ingress-nginx 查看控制器的外部 IP）。

  4. 自定义错误页面：若需修改错误页面内容，可基于 wangyanglinux/tools:errweb1.0 镜像二次构建，替换 /usr/share/nginx/html 下的 HTML 页面文件。

默认错误后端配置清单与部署指南

基于文档中通过 Helm 部署 Ingress-nginx 并启用默认错误后端 的核心需求，补充完整的 Helm 卸载命令、自定义 values.yaml 配置（指定错误后端镜像与端口），以及部署验证步骤，确保默认错误后端功能可直接启用。

一、核心操作流程说明

文档中提及 “卸载现有 Ingress-nginx” 和 “启用默认错误后端”，整体流程分为两步：

  1. 卸载旧版 Ingress-nginx：清理集群中已有的 Ingress-nginx 部署，避免版本或配置冲突。

  2. 通过 Helm 重新部署：使用自定义 values.yaml 启用默认错误后端，指定文档中的错误页面镜像（registry 仓库下的 errweb1.0 版本）和端口（80）。

二、完整配置与命令清单

1. 卸载现有 Ingress-nginx（文档核心命令）

执行以下命令卸载命名空间 ingress 下的 Ingress-nginx Helm Release（文档明确命令，补充执行说明）：

bash

# 卸载 ingress-nginx Release，-n 指定命名空间（文档明确为 ingress）
helm uninstall ingress-nginx -n ingress
# （可选）若命名空间不再使用，可删除命名空间（避免残留资源）
kubectl delete ns ingress

说明：若执行后提示 “release not found”，说明目标 Release 不存在，可直接跳过卸载步骤，进入部署环节。

2. 自定义 values.yaml（启用默认错误后端）

创建 values.yaml 文件，配置默认错误后端参数（文档提及 defaultBackend enabled: true、image: registry/xxx:errweb1.0、port:80，此处补全完整配置）：

yaml

# values.yaml：Ingress-nginx 自定义配置（重点启用默认错误后端）
controller:
  # （可选）基础配置，确保控制器正常运行
  replicaCount: 2  # 控制器副本数，保证高可用
  ingressClass:
    name: nginx  # IngressClass 名称，后续 Ingress 需引用此名称
    default: true  # 设为默认 IngressClass（可选）
# 核心：默认错误后端配置（文档核心需求）
defaultBackend:
  enabled: true  # 启用默认错误后端（文档明确开启）
  name: ingress-nginx-defaultbackend  # 错误后端服务/Deployment 名称（自定义）
  image:
    repository: registry/wangyanglinux/tools  # 文档隐含镜像仓库+镜像名（需替换为实际仓库地址）
    tag: "errweb1.0"  # 文档指定镜像标签
    pullPolicy: IfNotPresent  # 镜像拉取策略（默认，本地无镜像时拉取）
  port: 80  # 错误后端服务端口（文档明确为 80）
  resources:
    # （可选）资源限制，避免错误后端占用过多资源
    limits:
      cpu: 100m
      memory: 64Mi
    requests:
      cpu: 50m
      memory: 32Mi

关键补充：文档中 image: registry 仅为仓库前缀，需根据实际环境补充完整镜像路径（如 registry/wangyanglinux/tools），确保集群能拉取到 errweb1.0 镜像。

3. Helm 部署 Ingress-nginx（含默认错误后端）

执行以下命令，基于自定义 values.yaml 部署 Ingress-nginx，自动创建默认错误后端相关资源（Deployment + Service）：

bash

# 1. （可选）创建命名空间（若之前已删除）
kubectl create ns ingress
# 2. 添加 Ingress-nginx 官方 Helm 仓库（确保获取最新版本）
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
# 3. 部署 Ingress-nginx，引用自定义 values.yaml（启用错误后端）
helm install ingress-nginx ingress-nginx/ingress-nginx \
  -n ingress \
  -f values.yaml \
  --timeout 10m  # 延长超时时间，避免部署过慢导致失败

三、验证默认错误后端功能

1. 检查错误后端相关资源

部署完成后，确认默认错误后端的 Deployment 和 Service 已正常创建：

bash

# 查看错误后端 Deployment（名称与 values.yaml 中 defaultBackend.name 一致）
kubectl get deploy ingress-nginx-defaultbackend -n ingress
# 查看错误后端 Service（自动与 Deployment 关联）
kubectl get svc ingress-nginx-defaultbackend -n ingress

预期结果：Deployment 的 READY 状态为 1/1（默认副本数），Service 类型为 ClusterIP，端口为 80。

2. 测试错误后端生效

通过访问 “不存在的 Ingress 路由” 或 “后端服务异常的路由”，验证默认错误后端是否触发：

bash

# 1. 获取 Ingress 控制器的外部 IP（用于外部访问）
kubectl get svc ingress-nginx-controller -n ingress -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
# 2. 访问不存在的路径（触发 404 错误，应返回错误后端的自定义页面）
curl -I http:///nonexistent-path

预期结果：响应状态码为 404 Not Found，响应内容为 errweb1.0 镜像提供的自定义 404 页面（而非 Nginx 默认页面），说明默认错误后端已生效。

关键注意事项

  1. 镜像拉取问题：若错误后端 Deployment 处于 ImagePullBackOff 状态，需检查 values.yaml 中镜像路径是否正确，以及集群是否有权限访问该镜像仓库（私有仓库需配置 imagePullSecrets）。

  2. 错误状态码覆盖：默认错误后端会处理所有未匹配路由或后端服务异常的请求（返回 404、503 等状态码），若需自定义特定状态码的页面，可参考前文 “定制错误后端” 方案，通过 Ingress 注解补充配置。

  3. 版本兼容性：确保使用的 Ingress-nginx Helm 版本支持 defaultBackend 配置（官方 Helm 仓库 v4.0+ 均支持），可通过 helm search repo ingress-nginx 查看最新版本。

匹配请求头

基于文档中通过 Helm 部署 Ingress-nginx 并启用默认错误后端 的核心需求，补充完整的 Helm 卸载命令、自定义 values.yaml 配置（指定错误后端镜像与端口），以及部署验证步骤，确保默认错误后端功能可直接启用。

一、核心操作流程说明

文档中提及 “卸载现有 Ingress-nginx” 和 “启用默认错误后端”，整体流程分为两步：

  1. 卸载旧版 Ingress-nginx：清理集群中已有的 Ingress-nginx 部署，避免版本或配置冲突。

  2. 通过 Helm 重新部署：使用自定义 values.yaml 启用默认错误后端，指定文档中的错误页面镜像（registry 仓库下的 errweb1.0 版本）和端口（80）。

二、完整配置与命令清单

1. 卸载现有 Ingress-nginx（文档核心命令）

执行以下命令卸载命名空间 ingress 下的 Ingress-nginx Helm Release（文档明确命令，补充执行说明）：

bash

# 卸载 ingress-nginx Release，-n 指定命名空间（文档明确为 ingress）
helm uninstall ingress-nginx -n ingress
# （可选）若命名空间不再使用，可删除命名空间（避免残留资源）
kubectl delete ns ingress

说明：若执行后提示 “release not found”，说明目标 Release 不存在，可直接跳过卸载步骤，进入部署环节。

2. 自定义 values.yaml（启用默认错误后端）

创建 values.yaml 文件，配置默认错误后端参数（文档提及 defaultBackend enabled: true、image: registry/xxx:errweb1.0、port:80，此处补全完整配置）：

yaml

# values.yaml：Ingress-nginx 自定义配置（重点启用默认错误后端）
controller:
  # （可选）基础配置，确保控制器正常运行
  replicaCount: 2  # 控制器副本数，保证高可用
  ingressClass:
    name: nginx  # IngressClass 名称，后续 Ingress 需引用此名称
    default: true  # 设为默认 IngressClass（可选）
# 核心：默认错误后端配置（文档核心需求）
defaultBackend:
  enabled: true  # 启用默认错误后端（文档明确开启）
  name: ingress-nginx-defaultbackend  # 错误后端服务/Deployment 名称（自定义）
  image:
    repository: registry/wangyanglinux/tools  # 文档隐含镜像仓库+镜像名（需替换为实际仓库地址）
    tag: "errweb1.0"  # 文档指定镜像标签
    pullPolicy: IfNotPresent  # 镜像拉取策略（默认，本地无镜像时拉取）
  port: 80  # 错误后端服务端口（文档明确为 80）
  resources:
    # （可选）资源限制，避免错误后端占用过多资源
    limits:
      cpu: 100m
      memory: 64Mi
    requests:
      cpu: 50m
      memory: 32Mi

关键补充：文档中 image: registry 仅为仓库前缀，需根据实际环境补充完整镜像路径（如 registry/wangyanglinux/tools），确保集群能拉取到 errweb1.0 镜像。

3. Helm 部署 Ingress-nginx（含默认错误后端）

执行以下命令，基于自定义 values.yaml 部署 Ingress-nginx，自动创建默认错误后端相关资源（Deployment + Service）：

bash

# 1. （可选）创建命名空间（若之前已删除）
kubectl create ns ingress
# 2. 添加 Ingress-nginx 官方 Helm 仓库（确保获取最新版本）
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
# 3. 部署 Ingress-nginx，引用自定义 values.yaml（启用错误后端）
helm install ingress-nginx ingress-nginx/ingress-nginx \
  -n ingress \
  -f values.yaml \
  --timeout 10m  # 延长超时时间，避免部署过慢导致失败

三、验证默认错误后端功能

1. 检查错误后端相关资源

部署完成后，确认默认错误后端的 Deployment 和 Service 已正常创建：

bash

# 查看错误后端 Deployment（名称与 values.yaml 中 defaultBackend.name 一致）
kubectl get deploy ingress-nginx-defaultbackend -n ingress
# 查看错误后端 Service（自动与 Deployment 关联）
kubectl get svc ingress-nginx-defaultbackend -n ingress

预期结果：Deployment 的 READY 状态为 1/1（默认副本数），Service 类型为 ClusterIP，端口为 80。

2. 测试错误后端生效

通过访问 “不存在的 Ingress 路由” 或 “后端服务异常的路由”，验证默认错误后端是否触发：

bash

# 1. 获取 Ingress 控制器的外部 IP（用于外部访问）
kubectl get svc ingress-nginx-controller -n ingress -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
# 2. 访问不存在的路径（触发 404 错误，应返回错误后端的自定义页面）
curl -I http:///nonexistent-path

预期结果：响应状态码为 404 Not Found，响应内容为 errweb1.0 镜像提供的自定义 404 页面（而非 Nginx 默认页面），说明默认错误后端已生效。

关键注意事项

  1. 镜像拉取问题：若错误后端 Deployment 处于 ImagePullBackOff 状态，需检查 values.yaml 中镜像路径是否正确，以及集群是否有权限访问该镜像仓库（私有仓库需配置 imagePullSecrets）。

  2. 错误状态码覆盖：默认错误后端会处理所有未匹配路由或后端服务异常的请求（返回 404、503 等状态码），若需自定义特定状态码的页面，可参考前文 “定制错误后端” 方案，通过 Ingress 注解补充配置。

  3. 版本兼容性：确保使用的 Ingress-nginx Helm 版本支持 defaultBackend 配置（官方 Helm 仓库 v4.0+ 均支持），可通过 helm search repo ingress-nginx 查看最新版本。

ingress-nginx Ingress snippet.pdf

PDF · 167KB ·

632 字

按照文件中的格式提取资源清单

Kubernetes Ingress-nginx Snippet 配置资源清单与部署指南

基于文档中 Ingress-nginx 的 server-snippet 核心需求（实现移动端 UA 跳转），补充完整 Deployment（业务服务）、Service 及 Ingress 配置，同时整理 ConfigMap 调整命令，确保 snippet 注解与业务链路协同生效。

一、核心概念：server-snippet 注解

nginx.ingress.kubernetes.io/server-snippet 是 Nginx Ingress 的核心注解，作用是在 Ingress 对应的 Nginx 虚拟主机（server）配置块中插入自定义 Nginx 指令，支持条件判断、变量设置、重定向等复杂逻辑。文档中通过该注解实现 “移动端（Android/IPhone）访问时自动跳转至百度” 的场景，以下为完整落地配置。

二、完整资源清单

1. 业务服务：Deployment（snippet）

部署后端业务 Pod，为 Ingress 提供转发目标，补全文档中缺失的 replicas、containerPort、image 等字段：

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: snippet  # 部署名，与Service标签对应
  labels:
    app: snippet  # 标签，用于关联Service
spec:
  replicas: 2  # 副本数，确保业务高可用（文档缺失，建议设为2）
  selector:
    matchLabels:
      app: snippet  # 匹配Pod标签
  template:
    metadata:
      labels:
        app: snippet  # Pod标签，与selector一致
    spec:
      containers:
      - name: snippet-app  # 容器名
        image: nginx:1.25  # 业务镜像（文档缺失，选用稳定版Nginx作为示例）
        ports:
        - containerPort: 80  # 容器暴露端口（与Service的targetPort对应）
        resources:  # 资源限制，避免资源耗尽（可选）
          limits:
            cpu: "300m"
            memory: "256Mi"
          requests:
            cpu: "100m"
            memory: "128Mi"

2. 业务服务：Service（snippet）

暴露 Deployment 管理的 Pod，文档配置完整，仅补充命名空间字段：

yaml

apiVersion: v1
kind: Service
metadata:
  name: snippet  # 服务名，与Ingress后端配置一致
  namespace: default  # 与Deployment、Ingress同命名空间
  labels:
    app: snippet  # 标签，用于标识服务
spec:
  ports:
  - name: 80-80  # 端口名（自定义，便于识别）
    port: 80  # Service对外暴露端口
    protocol: TCP  # 协议类型（文档明确配置）
    targetPort: 80  # 转发到Pod的端口（与Deployment的containerPort一致）
  selector:
    app: snippet  # 标签选择器，匹配业务Pod
  type: ClusterIP  # 服务类型（仅集群内部访问，Ingress依赖此类型）

3. Ingress 配置（含 server-snippet 注解）

核心配置，通过 server-snippet 实现移动端 UA 跳转，补全文档中缺失的 path、pathType、backend 等字段：

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: snippet.xinxianghf.com  # Ingress名，与域名关联（文档指定）
  namespace: default  # 与业务服务同命名空间
  annotations:
    # 核心：自定义Nginx指令，实现移动端UA跳转
    nginx.ingress.kubernetes.io/server-snippet: |
      set $agentflag 0;  # 初始化标记变量为0
      # 匹配Android或IPhone的User-Agent，标记变量为1
      if ($http_user_agent ~* "(Android|IPhone)") {
        set $agentflag 1;
      }
      # 标记为1时，返回302临时重定向到百度
      if ($agentflag = 1) {
        return 302 http://www.baidu.com;
      }
spec:
  ingressClassName: nginx  # 指定Nginx Ingress控制器（文档隐含配置）
  rules:
  - host: snippet.xinxianghf.com  # 绑定的业务域名（文档核心域名）
    http:
      paths:
      - path: /  # 匹配域名下所有路径
        pathType: Prefix  # 路径匹配类型：前缀匹配（覆盖子路径）
        backend:
          service:
            name: snippet  # 转发到业务Service（与Service名一致）
            port:
              number: 80  # 转发到Service的80端口

4. ConfigMap 调整（允许 snippet 生效）

文档提及 “编辑 ingress-nginx-controller ConfigMap”，补充完整命令与配置，确保 server-snippet 注解不被禁用（部分环境默认限制 snippet 功能）：

bash

# 1. 编辑Ingress-nginx控制器的ConfigMap（命名空间为ingress，与控制器部署一致）
kubectl edit cm ingress-nginx-controller -n ingress
# 2. 在data字段下添加/修改以下配置，允许server-snippet生效
data:
  allow-snippet-annotations: "true"  # 关键配置：启用snippet相关注解
  # （其他默认配置保留，无需修改）

说明：若 ConfigMap 中已存在 allow-snippet-annotations: "true"，则无需修改；若为 "false"，需改为 "true"，否则 server-snippet 注解会被忽略。

三、部署与验证步骤

1. 部署资源

bash

# 1. 应用ConfigMap修改（若执行了步骤4，此步可跳过，修改会实时生效）
# 2. 部署Deployment和Service
kubectl apply -f deployment-snippet.yaml -f service-snippet.yaml
# 3. 部署Ingress
kubectl apply -f ingress-snippet.yaml

2. 验证配置正确性

bash

# 1. 查看Ingress是否正常创建，确认注解存在
kubectl get ingress snippet.xinxianghf.com -n default -o yaml | grep "server-snippet"
# 2. 查看Nginx Ingress控制器日志，确认配置已加载
kubectl logs -n ingress ingress-nginx-controller-xxxxxx-xxxx | grep "snippet.xinxianghf.com"

3. 测试 snippet 功能

通过 curl 模拟不同设备的 User-Agent，验证跳转逻辑：

bash

# 测试1：模拟PC端UA（不跳转，正常访问业务服务）
curl -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/118.0.0.0" \
  -I http://snippet.xinxianghf.com
# 预期响应：状态码 200 OK（返回业务服务内容）
# 测试2：模拟Android端UA（触发跳转，返回302）
curl -H "User-Agent: Mozilla/5.0 (Android 13; Mobile; rv:109.0) Firefox/118.0" \
  -I http://snippet.xinxianghf.com
# 预期响应：状态码 302 Found，Location: http://www.baidu.com（跳转百度）
# 测试3：模拟IPhone端UA（触发跳转，返回302）
curl -H "User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) Safari/605.1.15" \
  -I http://snippet.xinxianghf.com
# 预期响应：同上，状态码302且Location为百度

关键注意事项

  1. ConfigMap 生效范围：allow-snippet-annotations: "true" 是集群级配置，启用后所有 Ingress 均可使用 server-snippet，若需限制单个 Ingress，可通过 nginx.ingress.kubernetes.io/allow-snippet-annotations: "true" 单独在 Ingress 注解中配置。

  2. Nginx 指令语法：server-snippet 中插入的指令需符合 Nginx 语法（如 if 语句格式、变量引用），语法错误会导致 Ingress 配置加载失败，需通过控制器日志排查（kubectl logs -n ingress 控制器Pod名）。

  3. 跳转场景扩展：文档中跳转至百度，实际业务可修改 return 302 后的地址（如移动端专属域名 m.snippet.xinxianghf.com），或添加更多 UA 匹配规则（如 IPad、Windows Phone 等）。

  4. 与其他注解兼容性：server-snippet 优先级高于 Ingress 默认生成的 Nginx 配置，若同时配置 rewrite-target（路径重写），需注意指令执行顺序（snippet 指令在 rewrite 前执行）。

黑白名单

一、黑名单配置

文档提及 “ConfigMap 添加黑名单”“Annotations 添加黑名单” 两类方式，配套业务资源（Deployment/Service）如下：

1. 基础业务资源（黑名单 / 白名单通用）

1.1 Deployment（test-deploy/black-deploy）

文档中两类黑名单共用相似业务 Pod 配置，补充replicas、containerPort等必要字段：

yaml

# 对应文档“黑名单-ConfigMap”的业务Deployment（test-deploy）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deploy
  labels:
    app: test
spec:
  replicas: 1  # 文档隐含单副本，补充明确值
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: myapp
        image: wangyanglinux/myapp:v1.0  # 文档指定镜像
        ports:
        - containerPort: 80  # 补充必要端口，与Service目标端口对应
---
# 对应文档“黑名单-Annotations”的业务Deployment（black-deploy）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: black-deploy
  labels:
    app: black
spec:
  replicas: 1  # 补充明确副本数
  selector:
    matchLabels:
      app: black
  template:
    metadata:
      labels:
        app: black
    spec:
      containers:
      - name: myapp
        image: wangyanglinux/myapp:v1.0  # 文档指定镜像
        ports:
        - containerPort: 80

1.2 Service（test-svc/black-svc）

文档中 Service 配置较完整，补充命名空间字段：

yaml

# 对应“黑名单-ConfigMap”的Service（test-svc）
apiVersion: v1
kind: Service
metadata:
  name: test-svc
  namespace: default  # 补充默认命名空间
  labels:
    app: test
spec:
  ports:
  - name: 80-80
    port: 80
    protocol: TCP
    targetPort: 80  # 与Deployment容器端口一致
  selector:
    app: test
  type: ClusterIP
---
# 对应“黑名单-Annotations”的Service（black-svc）
apiVersion: v1
kind: Service
metadata:
  name: black-svc
  namespace: default  # 补充命名空间
  labels:
    app: black
spec:
  ports:
  - name: 80-80
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: black
  type: ClusterIP

2. 黑名单 - ConfigMap 配置（集群级）

文档提及 “kubectl 编辑 ConfigMap 添加 block-cidrs”，补充完整命令与配置：

bash

# 1. 编辑Ingress-nginx控制器的ConfigMap（命名空间为ingress，文档隐含）
kubectl edit cm ingress-nginx-controller -n ingress
# 2. 在data字段下添加黑名单配置（block-cidrs：需拦截的IP/网段，多个用逗号分隔）
data:
  allow-snippet-annotations: "true"  # 文档提及allow-sn，补充完整键名
  block-cidrs: "192.168.10.10/32,10.0.0.0/24"  # 示例黑名单IP/网段，按需修改

2.1 配套 Ingress（test.xinxianghf.com）

文档中 Ingress 缺失路径与后端配置，补充完整：

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test.xinxianghf.com
  namespace: default
spec:
  ingressClassName: nginx  # 补充Ingress控制器类型
  rules:
  - host: test.xinxianghf.com  # 文档指定域名
    http:
      paths:
      - path: /
        pathType: Prefix  # 补充路径匹配类型
        backend:
          service:
            name: test-svc  # 关联业务Service
            port:
              number: 80

3. 黑名单 - Annotations 配置（Ingress 级）

文档提及通过server-snippet注解添加黑名单，补充完整 Ingress 配置：

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: black.xinxianghf.com
  namespace: default
  annotations:
    # 文档指定注解：deny单个IP，allow all允许其他IP
    nginx.ingress.kubernetes.io/server-snippet: |
      deny 192.168.10.11;  # 文档指定拦截IP
      allow all;
spec:
  ingressClassName: nginx  # 补充控制器类型
  rules:
  - host: black.xinxianghf.com  # 文档指定域名
    http:
      paths:
      - path: /
        pathType: Prefix  # 补充路径匹配类型
        backend:
          service:
            name: black-svc  # 关联业务Service
            port:
              number: 80

二、白名单配置

文档提及 “ConfigMap 添加白名单”“Annotations 添加白名单” 两类方式，基于通用业务资源补充配置：

1. 白名单 - ConfigMap 配置（集群级）

文档提及 “kubectl 设置 whitelist”，补充完整命令与配置：

bash

# 1. 编辑Ingress-nginx控制器的ConfigMap
kubectl edit cm ingress-nginx-controller -n ingress
# 2. 在data字段下添加白名单配置（whitelist-source-range：仅允许的IP/网段）
data:
  allow-snippet-annotations: "true"  # 文档提及allow-sn，补充完整
  whitelist-source-range: "192.168.20.0/24,172.16.0.5/32"  # 示例白名单，按需修改

1.1 配套 Ingress（复用 test-deploy/test-svc）

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-whitelist-cm.xinxianghf.com
  namespace: default
spec:
  ingressClassName: nginx
  rules:
  - host: test-whitelist-cm.xinxianghf.com  # 自定义白名单域名
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: test-svc  # 关联通用业务Service
            port:
              number: 80

2. 白名单 - Annotations 配置（Ingress 级）

文档提及通过注解配置白名单，补充完整 Ingress（基于 white-deploy/white-svc）：

yaml

# 白名单业务Deployment（white-deploy）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: white-deploy
  labels:
    app: white
spec:
  replicas: 1  # 文档隐含单副本，补充明确值
  selector:
    matchLabels:
      app: white
  template:
    metadata:
      labels:
        app: white
    spec:
      containers:
      - name: myapp
        image: wangyanglinux/myapp:v1.0  # 文档指定镜像
        ports:
        - containerPort: 80
---
# 白名单业务Service（white-svc）
apiVersion: v1
kind: Service
metadata:
  name: white-svc
  namespace: default
  labels:
    app: white
spec:
  ports:
  - name: 80-80
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: white
  type: ClusterIP
---
# 白名单-Annotations的Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: white.xinxianghf.com
  namespace: default
  annotations:
    # 文档隐含通过注解配置白名单，使用Ingress-nginx官方注解
    nginx.ingress.kubernetes.io/whitelist-source-range: "192.168.20.10/32,10.10.0.0/24"  # 示例白名单IP/网段
spec:
  ingressClassName: nginx
  rules:
  - host: white.xinxianghf.com  # 自定义白名单域名
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: white-svc  # 关联白名单业务Service
            port:
              number: 80

验证命令（文档隐含需求补充）

bash

# 1. 验证ConfigMap配置是否生效
kubectl get cm ingress-nginx-controller -n ingress -o jsonpath='{.data}'
# 2. 验证黑名单拦截（示例：访问被block的IP 192.168.10.10）
curl -x 192.168.10.10:80 http://test.xinxianghf.com  # 预期返回403 Forbidden
# 3. 验证白名单允许（示例：从白名单IP 192.168.20.5访问）
curl -x 192.168.20.5:80 http://white.xinxianghf.com  # 预期返回200 OK

 速率限制

1. Deployment（应用部署控制器）

yaml

apiVersion: apps/v1  # 原文档缺失，补充 Deployment 标准 API 版本
kind: Deployment
metadata:
  labels:
    app: speed
  name: speed-deploy  # 部署名称
  namespace: default  # 原文档未指定，默认使用 default 命名空间
spec:
  replicas: 1  # 原文档缺失，补充默认副本数 1（可根据需求调整）
  selector:
    matchLabels:
      app: speed  # 与 Pod 标签匹配，用于筛选管理的 Pod
  template:
    metadata:
      labels:
        app: speed  # Pod 标签，与 selector 对应
    spec:
      containers:
      - name: speed-container  # 原文档缺失，补充容器名称
        image: nginx:alpine  # 原文档缺失，补充轻量测试镜像（可替换为实际业务镜像）
        ports:
        - containerPort: 80  # 容器暴露端口，与 Service targetPort 对应
2. Service（集群内部服务暴露）

yaml

apiVersion: v1  # 原文档缺失，补充 Service 标准 API 版本
kind: Service
metadata:
  labels:
    app: speed
  name: speed-svc  # 服务名称，与 Ingress backend 对应
  namespace: default  # 与 Deployment 同命名空间，确保可访问
spec:
  ports:
  - name: 80-80  # 端口名称（自定义，用于标识）
    port: 80  # Service 暴露端口
    protocol: TCP  # 传输协议（默认 TCP）
    targetPort: 80  # 指向 Pod 内部端口（与容器 containerPort 对应）
  selector:
    app: speed  # 标签选择器，与 Deployment Pod 标签匹配
  type: ClusterIP  # 服务类型：仅集群内部可访问
3. Ingress（外部流量入口配置）

yaml

apiVersion: networking.k8s.io/v1  # 原文档已提及，确认 Ingress 标准 API 版本
kind: Ingress
metadata:
  name: speed.xinxianghf.com  # Ingress 名称，与域名对应
  namespace: default  # 与后端 Service 同命名空间
  # 原文档未提及速率限制注解，若需启用 Ingress-Nginx 速率限制，可补充如下注解（示例）：
  # annotations:
  #   nginx.ingress.kubernetes.io/rate-limit-status-code: "429"  # 限流返回状态码
  #   nginx.ingress.kubernetes.io/rate-limit-window: "1m"  # 限流窗口
  #   nginx.ingress.kubernetes.io/rate-limit-rps: "10"  # 每秒请求数限制
spec:
  rules:
  - host: speed.xinxianghf.com  # 绑定的域名（需提前解析到 Ingress 控制器 IP）
    http:
      paths:
      - path: "/"  # 匹配的路径（根路径）
        pathType: Prefix  # 路径匹配类型：前缀匹配
        backend:
          service:
            name: speed-svc  # 关联的后端 Service 名称
            port:
              number: 80  # 关联的 Service 端口（与 Service port 对应）
  # 若需 HTTPS，可补充 tls 配置（示例）：
  # tls:
  # - hosts:
  #   - speed.xinxianghf.com
  #   secretName: speed-tls-secret  # 存储证书的 Secret 名称
4. 速率限制测试命令（原文档提及）

用于测试 Ingress 速率限制是否生效，通过 ab（Apache Bench）工具模拟并发请求：

bash

# 语法：ab -c 并发数 -n 总请求数 http://目标域名/
$ ab -c 10 -n 100 http://speed.xinxianghf.com/  # 示例：10 并发、100 总请求测试根路径
  • 若速率限制配置生效，当请求超过限制时，会收到 429 Too Many Requests 响应；
  • 需确保节点已安装 ab 工具（如 CentOS 可通过 yum install httpd-tools 安装，Ubuntu 可通过 apt install apache2-utils 安装）。

金丝雀发布、灰度发布=

1. Deployment（v1 应用部署）

yaml

# 文档核心配置，补充K8s必填的apiVersion（否则无法创建资源）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: v1-deploy
  labels:
    app: v1
spec:
  replicas: 1  # 文档未指定副本数，默认1（可根据需求调整）
  selector:
    matchLabels:
      app: v1
  template:
    metadata:
      labels:
        app: v1
    spec:
      containers:
      - name: v1-container  # 文档未指定容器名，补充默认名（必填）
        image: nginx:alpine  # 文档未指定镜像，补充轻量测试镜像（实际替换为你的业务镜像）
        ports:
        - containerPort: 80  # 文档未指定端口，补充默认80（与Service目标端口一致）
2. Service（v1 集群内服务暴露）

yaml

# 补充K8s必填的apiVersion
apiVersion: v1
kind: Service
metadata:
  name: v1-svc
  labels:
    app: v1
spec:
  ports:
  - name: 80-80
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: v1
  type: ClusterIP

3. Ingress（v1 外部流量入口）

yaml

# 文档已指定apiVersion，直接沿用
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: v1.xinxianghf.com
  namespace: default
spec:
  rules:
  - host: svc.xinxianghf.com  # 文档指定的域名，需提前解析到Ingress Controller IP
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: v1-svc
            port:
              number: 80
1. Deployment（v2 金丝雀应用部署）

yaml

# 补充K8s必填的apiVersion
apiVersion: apps/v1
kind: Deployment
metadata:
  name: v2-deploy  # 文档隐含与v1区分，补充名称
  labels:
    app: v2
spec:
  replicas: 1  # 默认1副本（灰度初期建议少副本）
  selector:
    matchLabels:
      app: v2
  template:
    metadata:
      labels:
        app: v2
    spec:
      containers:
      - name: v2-container  # 补充容器名（必填）
        image: nginx:1.25-alpine  # 补充与v1不同的测试镜像（实际替换为你的v2业务镜像）
        ports:
        - containerPort: 80  # 与v1端口一致，保证流量兼容性
2. Service（v2 金丝雀服务暴露）

yaml

# 补充K8s必填的apiVersion
apiVersion: v1
kind: Service
metadata:
  name: v2-svc
  labels:
    app: v2
spec:
  ports:
  - name: 80-80
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: v2
  type: ClusterIP
3. Ingress（v2 金丝雀流量控制）

yaml

# 文档已指定apiVersion和核心canary注解，直接沿用并补全缺失字段
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: v2.xinxianghf.com
  namespace: default
  annotations:
    # 文档指定的金丝雀核心配置，10%流量流向v2
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  rules:
  - host: svc.xinxianghf.com  # 与v1同域名，实现流量分流
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: v2-svc
            port:
              number: 80
测试命令

代理后端https协议

1. Deployment（后端 HTTPS 服务部署）

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: proxyhttps  # 标签，用于关联Service的selector
  name: proxyhttps-deploy  # 文档缺失部署名称，补充后与业务标识一致（必填，否则无法创建资源）
spec:
  replicas: 1  # 文档缺失副本数，补充默认值1（可根据服务压力调整，生产环境建议≥2）
  selector:
    matchLabels:
      app: proxyhttps  # 匹配Pod标签，确保Deployment能管理对应Pod（核心关联配置，不匹配则Pod无法被管控）
  template:
    metadata:
      labels:
        app: proxyhttps  # 与selector.matchLabels一致，形成Deployment-Pod关联
    spec:
      containers:
      - name: proxyhttps-container  # 文档缺失容器名称，补充后便于识别（必填）
        image: wangyanglinux/tools:httpsv1  # 文档指定的后端HTTPS服务镜像（无需修改，直接使用）
        ports:
        - containerPort: 443  # 文档缺失容器暴露端口，补充443（后端是HTTPS服务，默认端口443，需与Service.targetPort一致）
2. Service（后端 HTTPS 服务集群内暴露）

yaml

apiVersion: v1  # 文档缺失Service的apiVersion，补充标准值v1（必填）
kind: Service
metadata:
  labels:
    app: proxyhttps  # 与Deployment标签一致，便于资源归类
  name: proxyhttps-svc  # 服务名称，将被Ingress关联（文档已提供，无需修改）
spec:
  ports:
  - name: 443-443  # 端口名称，仅用于标识（无实际功能，便于运维识别端口用途）
    port: 443  # Service暴露的端口（集群内访问该Service的端口）
    protocol: TCP  # 文档缺失协议类型，补充默认值TCP（网络传输协议，HTTPS基于TCP）
    targetPort: 443  # 转发到Pod的端口（需与Deployment中containerPort一致，否则流量无法到达后端服务）
  selector:
    app: proxyhttps  # 匹配Deployment创建的Pod标签，实现Service-Pod流量转发（核心关联配置）
  type: ClusterIP  # 服务类型：仅集群内可访问（后端服务无需对外暴露，由Ingress统一入口）
3. Ingress（代理后端 HTTPS 服务的入口配置）

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    # 核心注解：告诉Ingress-Nginx控制器，用HTTPS协议与后端Service通信（默认是HTTP，不配置则代理失败）
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
  name: proxyhttps.xinxianghf.com  # Ingress名称，与域名一致便于识别
  namespace: default  # 命名空间，与Deployment/Service一致（确保资源在同一命名空间，否则无法关联）
spec:
  rules:
  - host: proxyhttps.xinxianghf.com  # 外部访问域名（需提前解析到Ingress-Nginx控制器的IP，否则无法访问）
    http:
      paths:
      - backend:
          service:
            name: proxyhttps-svc  # 关联后端Service名称（必须与上面Service.name一致，否则无法找到后端服务）
            port:
              number: 443  # 关联Service暴露的端口（与Service.port一致）
        path: /  # 匹配外部访问的路径（根路径，即访问域名时所有路径都转发到后端）
        # 路径匹配类型：由Ingress控制器（此处为nginx）自行决定匹配规则（灵活适配nginx的路径匹配逻辑，无需手动定义复杂规则）
        pathType: ImplementationSpecific

四层代理

1. ConfigMap（UDP 服务配置映射）

yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-ingress-udp-configmap
  namespace: ingress
data:
  # 格式：“外部暴露UDP端口: 后端服务所在命名空间/后端服务名:后端服务UDP端口”（53为常见DNS UDP端口，示例后端服务为default命名空间的dns-svc:53）
  "53": "default/dns-svc:53"

1. ConfigMap（TCP 服务配置映射）

yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-ingress-tcp-configmap
  namespace: ingress
data:
  # 格式：“外部暴露TCP端口: 后端服务所在命名空间/后端服务名:后端服务TCP端口”（关联下方proxyhttps-svc服务）
  "9000": "default/proxyhttps-svc:443"
2. Deployment（后端 TCP 服务部署）

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: proxyhttps
  name: proxyhttps-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: proxyhttps
  template:
    metadata:
      labels:
        app: proxyhttps
    spec:
      containers:
      - name: myapp
        image: wangyanglinux/tools:httpsv1
3. Service（后端 TCP 服务集群内暴露）

yaml

apiVersion: v1
kind: Service
metadata:
  labels:
    app: proxyhttps
  name: proxyhttps-svc
spec:
  ports:
  - name: 443-443
    port: 443
    protocol: TCP
    targetPort: 443
  selector:
    app: proxyhttps
  type: ClusterIP

 链路追踪

下载官方文件

wget 

把原文件改成apps/v1、标签选择器