企业官网建设流程全解析

摘要：梳理K8s核心知识点，涵盖资源管理三种方式、kubectl全套命令、Pod概念与控制器管理、YAML资源清单全参数、QoS等级、Init初始化容器、三大探针、Service四种类型、IPVS模式、MetalLB、Ingress-nginx七层代理与高级功能、Canary金丝雀灰度发布。

1.K8s资源基础与kubectl核心命令

1.1 资源管理概述

在Kubernetes中，所有内容都抽象为资源，用户通过操作资源管理集群。K8s最小管理单元是Pod，容器运行在Pod内部；K8s一般不直接管理Pod，而是通过Pod控制器管理；Pod服务访问靠Service；数据持久化靠Volume/PVC/ConfigMap/Secret。

1.2 三种资源管理方式

1.命令式对象管理 kubectl run/delete/get 简单却只能操作活动对象，无法审计跟踪
2.命令式对象配置 kubectl create/patch -f xxx.yaml 可以审计跟踪但是配置文件多操作繁琐
3.声明式对象配置 kubectl apply -f xxx.yaml 支持目录批量操作但在异常情况难调试

1.3 kubectl核心命令

基础语法：kubectl [command] [type] [name] [flags]

1.# 集群信息
kubectl version
kubectl cluster-info
kubectl api-resources # 查看所有资源类型

2.# 资源操作

kubectl create deployment web --image nginx --replicas 2 kubectl get deployments.apps kubectl explain deployment.spec kubectl edit deployments.apps web kubectl patch deployments.apps web -p '{"spec":{"replicas":4}}' kubectl delete deployments.apps web

3.# 运行调试

kubectl run testpod --image nginx kubectl expose pod testpod --port 80 --target-port 80 kubectl describe pods testpod # 排查报错首选 kubectl logs pods/testpod kubectl exec -it pods/nginx -- /bin/bash kubectl cp 本地文件 nginx:/ # 上传文件到pod kubectl cp nginx:/路径 本地路径 # 下载pod文件

4.# 标签管理

kubectl get pods --show-labels kubectl label pods nginx app=lee kubectl label pods nginx app=web --overwrite kubectl label pods nginx app-

5.# 生成yaml模板（--dry-run=client只输出不创建）

kubectl create deployment --image nginx web --dry-run=client -o yaml > web.yml kubectl run pod1 --image myapp:v1 --dry-run=client -o yaml > pod.yml

1.4 实战：从零部署一个Nginx应用

下面通过一个完整示例，演示如何用声明式配置（kubectl apply）从零部署一个Nginx应用，并对外提供服务。整个过程包含资源清单编写、部署、验证和清理四个步骤。

步骤一：编写Deployment资源清单

创建文件nginx-deploy.yaml，内容如下：

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-demo labels: app: nginx-demo spec: replicas: 2 selector: matchLabels: app: nginx-demo template: metadata: labels: app: nginx-demo spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 200m memory: 256Mi

关键步骤注释：

• apiVersion/kind：声明资源类型为Deployment，使用apps/v1版本。
• replicas: 2：期望运行2个Pod副本，控制器保证始终有2个可用。
• selector.matchLabels：控制器通过该标签选择并管理Pod。
• template.metadata.labels：Pod模板标签，必须与selector匹配。
• resources：requests是调度依据，limits是资源上限，二者相等时QoS等级为Guaranteed。

步骤二：编写Service资源清单

创建文件nginx-svc.yaml，内容如下：

apiVersion: v1 kind: Service metadata: name: nginx-demo-svc spec: type: ClusterIP selector: app: nginx-demo ports: - port: 80 targetPort: 80 protocol: TCP

关键步骤注释：

• type: ClusterIP：默认类型，分配集群内部虚拟IP，仅集群内可访问。
• selector.app: nginx-demo：Service通过该标签自动发现后端Pod，并维护Endpoints列表。
• port/targetPort：port是Service对外端口，targetPort是Pod容器端口，这里均为80。

步骤三：部署并验证

执行以下命令完成部署和验证：

# 1. 应用资源清单 kubectl apply -f nginx-deploy.yaml kubectl apply -f nginx-svc.yaml 2. 查看Deployment和Pod状态 kubectl get deployment nginx-demo kubectl get pods -l app=nginx-demo 3. 查看Service和Endpoints kubectl get svc nginx-demo-svc kubectl get endpoints nginx-demo-svc 4. 集群内访问测试 kubectl run test-pod --image=busybox --rm -it -- sh -c "wget -qO- http://nginx-demo-svc" 5. 查看Pod日志 kubectl logs -l app=nginx-demo

预期输出说明：

• kubectl get deployment：显示READY 2/2，表示2个副本全部就绪。
• kubectl get pods：2个Pod状态均为Running，READY列为1/1。
• kubectl get svc：Service获得一个ClusterIP（如10.97.xx.xx），CLUSTER-IP不为None。
• kubectl get endpoints：Endpoints列出2个Pod的IP和端口，格式如10.244.1.5:80,10.244.2.7:80。
• wget测试：返回Nginx默认欢迎页HTML，包含Welcome to nginx!字样。
• kubectl logs：输出Nginx访问日志，包含刚才wget请求的GET /记录。

步骤四：清理资源

验证完成后，执行以下命令清理资源：

kubectl delete -f nginx-deploy.yaml kubectl delete -f nginx-svc.yaml

预期输出说明：两条命令均返回deleted，随后kubectl get all -l app=nginx-demo不再显示任何相关资源。

2 Pod核心概念与控制器管理

2.1 Pod核心概念

Pod是K8s最小可部署计算单元，代表集群中运行的一个进程，每个Pod有唯一IP。一个Pod类似豌豆荚，包含一个或多个容器，多容器间共享IPC、Network和UTC namespace，共用网络栈，可直接用localhost互访。

注意：同一Pod多容器不能占用相同端口，否则端口冲突启动报错。

2.2 自主式Pod VS 控制器管理Pod

1.自主式Pod（生产不推荐）：直接`kubectl run`创建。优点是灵活、方便学习调试；缺点是无自愈、不支持扩缩容和滚动更新、Pod删除不会重建、维护成本高。

2.控制器管理Pod（生产强烈推荐Deployment）：

自动故障恢复：Pod宕机/删除自动重建，维持副本数；

健康检查自愈：支持存活/就绪探针；

扩缩容与HPA：手动或基于指标自动伸缩；

滚动更新与回滚：逐步替换旧版本，出问题一键回滚；

声明式配置：YAML版本控制，CI/CD友好；

服务发现负载均衡：Service自动发现后端Pod。

kubectl create deployment timinglee --image nginx kubectl scale deployment timinglee --replicas 6 # 扩容 kubectl scale deployment timinglee --replicas 2 # 缩容

2.3 应用版本更新与回滚

kubectl create deployment timinglee --image myapp:v1 --replicas 2 kubectl expose deployment timinglee --port 80 --target-port 80 kubectl rollout history deployment timinglee # 查看历史版本 kubectl set image deployments/timinglee myapp=myapp:v2 # 升级v2 kubectl rollout undo deployment timinglee --to-revision 1 # 回滚v1

3 Pod资源清单YAML与QoS等级

3.1 YAML四大必写字段

apiVersion：API版本，kubectl api-versions查询；

kind：资源类型（Pod/Deployment/Service）；

metadata：元数据（name/labels/namespace）；

spec：期望状态定义。

3.2 关键spec参数

spec.containers[] 容器列表（name/image）
imagePullPolicy 镜像拉取策略：Always/IfNotPresent/Never
command/args 容器启动命令与参数
ports containerPort/hostPort/protocol
env[] 环境变量
resources.limits 资源使用上限（cpu/memory）
resources.requests 调度请求资源（调度器选节点依据）
spec.restartPolicy 重启策略：Always/OnFailure/Never（Deployment只能Always）
nodeSelector 节点标签选择，指定Pod调度节点
hostNetwork 是否使用宿主机网络

3.3 常用YAML示例

单容器Pod：

apiVersion: v1 kind: Pod metadata: labels: {run: timing} name: timinglee spec: containers: - image: myapp:v1 name: timinglee

多容器Pod（业务+sidecar，注意端口不冲突）：

apiVersion: v1 kind: Pod metadata: name: test spec: containers: - image: myapp:v1 name: myapp1 - image: busyboxplus:latest name: busybox command: ["/bin/sh","-c","sleep 1000000"]

资源限制+节点选择+宿主机网络：

apiVersion: v1 kind: Pod metadata: {name: test} spec: nodeSelector: kubernetes.io/hostname: k8s-node1 hostNetwork: true restartPolicy: Always containers: - image: myapp:v1 name: myapp resources: limits: {cpu: 500m, memory: 100M} requests: {cpu: 500m, memory: 100M}

3.4 QoS服务质量等级

资源限制影响Pod的QoS优先级，节点资源紧张时低优先级Pod优先被驱逐：

资源设定 QoS等级
未设定资源限制 BestEffort（最低）
设定且limits≠requests Burstable（中等）
设定且limits=requests Guaranteed（最高）

4.Pod生命周期：Init容器与三大探针

4.1 Init初始化容器

Pod可配置一个或多个Init容器，串行执行，全部成功后才启动业务主容器。

特点：Init容器必须运行到完成，下一个才执行；不支持readiness探针；Init失败kubelet反复重启Pod（restartPolicy=Never则不重启）。

用途：前置环境初始化、等待外部依赖就绪、下载配置、安全执行初始化工具、访问业务容器不能访问的Secret权限。

apiVersion: v1 kind: Pod metadata: {name: initpod} spec: containers: - image: myapp:v1 name: myapp initContainers: - name: init-myservice image: busybox command: ["sh","-c","until test -e /testfile;do echo waiting; sleep 2;done"]

注意：Init容器等待/testfile存在才完成，手动touch /testfile后主容器启动。

4.2 三大探针

探针由kubelet定期执行诊断，支持三种方式：ExecAction（容器内执行命令，返回码0成功）、TCPSocketAction（TCP端口探测）、HTTPGetAction（HTTP Get，状态码200-399成功）。

1.livenessProbe存活探针: 判断容器是否活着 杀死容器，按重启策略重启
2.readinessProbe就绪探针 : 判断容器是否可接收流量 不杀容器，从Service端点列表移除，探测成功重新加入
3.startupProbe启动探针:判断应用是否启动完成 失败杀容器重启；成功前禁用另外两个探针，适合慢启动应用

注意：三探针同时存在时先执行startupProbe，成功后liveness/readiness才生效；startup只探测一次，另外两个持续探测直到容器消亡。

livenessProbe存活探针示例（TCP探测8080，服务实际监听80，会反复CrashLoopBackOff）：apiVersion: v1 kind: Pod metadata: {name: liveness} spec: containers: - image: myapp:v1 name: myapp livenessProbe: tcpSocket: {port: 8080} initialDelaySeconds: 3 # 启动后等待秒数 periodSeconds: 1 # 探测间隔 timeoutSeconds: 1 # 超时时间

readinessProbe就绪探针示例（HTTP探测/test.html，不存在则Pod不加入Service后端）：apiVersion: v1 kind: Pod metadata: {name: readiness} spec: containers: - image: myapp:v1 name: myapp readinessProbe: httpGet: path: /test.html port: 80 initialDelaySeconds: 1 periodSeconds: 3

5 Service微服务与IPVS模式

5.1 Service概念

Service是一组提供相同服务的Pod对外开放的接口，实现**服务发现和四层负载均衡。Service默认只支持四层TCP/UDP，七层HTTP需通过Ingress实现。Service通过spec.selector标签匹配后端Pod，维护Endpoints端点列表。

5.2 Deployment+Service联合部署

apiVersion: apps/v1 kind: Deployment metadata: labels: {app: timinglee} name: timinglee spec: replicas: 2 selector: {matchLabels: {app: timinglee}} template: metadata: {labels: {app: timinglee}} spec: containers: - image: myapp:v1 name: myapp --- apiVersion: v1 kind: Service metadata: labels: {app: timinglee} name: timinglee spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: {app: timinglee}

5.3 IPVS模式

Service由kube-proxy+iptables实现。大量Pod时iptables规则海量，CPU开销大。**IPVS模式**基于内核负载均衡模块，性能更高，支持更大规模Pod。

配置三步骤：

# 1.所有节点安装ipvsadm yum install ipvsadm -y # 2.修改kube-proxy configmap，mode改为ipvs kubectl -n kube-system edit cm kube-proxy # mode: "ipvs" # 3.重启kube-proxy pod使配置生效 kubectl -n kube-system get pods | awk '/kube-proxy/{system("kubectl -n kube-system delete pods "$1)}' ipvsadm -Ln # 验证ipvs规则

注意：切换ipvs后生成虚拟网卡kube-ipvs0，所有Service ClusterIP绑定到此网卡。

6 Service四大类型与MetalLB

6.1 ClusterIP（默认）

分配集群虚拟IP，仅集群内部访问。DNS域名格式：svc名称.namespace.svc.cluster.local。

dig timinglee.default.svc.cluster.local @10.96.0.10 # 解析到ClusterIP 10.97.59.25

6.2 Headless无头服务

clusterIP: None，不分配ClusterIP，kube-proxy不处理，DNS直接解析到后端Pod真实IP，常用于StatefulSet有状态应用。

spec:
type: ClusterIP
clusterIP: None

注意：dig解析返回所有Pod的IP地址。

6.3 NodePort

在每个集群节点打开物理端口，外部访问任意节点IP:NodePort。默认端口范围30000-32767，超出报错。自定义端口范围：修改apiserver启动参数--service-node-port-range=30000-40000，api-server自动重启。

spec: type: NodePort ports: - port: 80 targetPort: 80 # nodePort: 31771 # 可指定，不指定则自动分配

6.4 LoadBalancer

云厂商环境自动分配公网VIP；裸金属环境需要MetalLB提供外部IP。未安装MetalLB时EXTERNAL-IP显示<pending>。

6.5 ExternalName

不分配集群IP，通过DNS CNAME转发到外部域名，适合外部业务迁移到集群的过渡阶段（IP变化但域名固定）。

spec: type: ExternalName externalName: www.timinglee.org

6.6 MetalLB裸金属实现LoadBalancer

MetalLB为LoadBalancer类型Service分配VIP。部署步骤：

1.kube-proxy开启ipvs并设置strictARP: true，重启kube-proxy；

2.下载metallb-native.yaml，修改镜像地址与harbor一致并上传镜像；

3.部署MetalLB（controller+speaker组件）；

4.配置IPAddressPool地址池和L2Advertisement二层宣告；

apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: first-pool namespace: metallb-system spec: addresses: - 172.25.254.50-172.25.254.99 --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: example namespace: metallb-system spec: ipAddressPools: - first-pool

注意：部署后LoadBalancer Service自动从地址池分配EXTERNAL-IP，集群外可直接访问。

7 Ingress-nginx七层反向代理

7.1 Ingress概念

Service是四层，Ingress提供七层HTTP/HTTPS反向代理。由两部分组成：Ingress Controller（实际运行Nginx程序执行代理）+Ingress资源对象（定义路由规则）。业界Nginx、HAProxy、Envoy、Traefik均有对应Ingress Controller。

7.2 部署Ingress-nginx

1.下载baremetal版deploy.yaml；

2.修改镜像地址上传harbor；

3.kubectl apply -f deploy.yaml部署；

4.将ingress-nginx-controller的Service改为LoadBalancer（配合MetalLB分配对外IP）。

kubectl -n ingress-nginx get svc
# NAME TYPE EXTERNAL-IP PORT(S)
# ingress-nginx-controller LoadBalancer 172.25.254.50 80:34512/TCP,443:34727/TCP

7.3 基础Ingress示例

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: {name: test-ingress} spec: ingressClassName: nginx rules: - http: paths: - backend: service: name: timinglee-svc port: {number: 80} path: / pathType: Prefix

pathType四种：Prefix（前缀匹配）、Exact（精确匹配）、ImplementationSpecific（特定实现，支持正则）、Regular expression（正则匹配）。

注意：Ingress必须和后端Service处于同一namespace。

8.Ingress高级功能

8.1 基于路径转发

访问/v1转发myapp-v1，/v2转发myapp-v2，用rewrite-target重写URL：

metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: www.timinglee.org http: paths: - {path: /v1, pathType: Prefix, backend: {service: {name: myapp-v1, port: {number: 80}}}} - {path: /v2, pathType: Prefix, backend: {service: {name: myapp-v2, port: {number: 80}}}}

8.2 基于域名虚拟主机

不同域名转发不同后端：

spec: rules: - host: myappv1.timinglee.org http: {paths: [{path: /, pathType: Prefix, backend: {service: {name: myapp-v1, port: {number: 80}}}}]} - host: myappv2.timinglee.org http: {paths: [{path: /, pathType: Prefix, backend: {service: {name: myapp-v2, port: {number: 80}}}}]}

8.3 TLS HTTPS加密

# 生成证书 openssl req -newkey rsa:2048 -nodes -keyout tls.key -x509 -days 365 -subj "/CN=nginxsvc/O=nginxsvc" -out tls.crt # 创建tls类型secret kubectl create secret tls web-tls-secret --key tls.key --cert tls.crt spec: tls: - hosts: [myapp-tls.timinglee.org] secretName: web-tls-secret

8.4 BasicAuth认证

dnf install httpd-tools -y htpasswd -cm auth lee # 生成密码文件 kubectl create secret generic auth-web --from-file auth metadata: annotations: nginx.ingress.kubernetes.io/auth-type: basic nginx.ingress.kubernetes.io/auth-secret: auth-web nginx.ingress.kubernetes.io/auth-realm: "Please input username and password"

测试：curl -k https://域名 -u lee:密码

8.5 rewrite重定向

nginx.ingress.kubernetes.io/app-root: /hostname.html：访问根路径自动跳转指定页面；

正则重写（解决带前缀路径问题）：

metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: /$2 nginx.ingress.kubernetes.io/use-regex: "true" spec: rules: - host: myapp-tls.timinglee.org http: paths: - {path: /lee(/|$)(.*), pathType: ImplementationSpecific, backend: {service: {name: myapp-v1, port: {number: 80}}}}

9.Canary金丝雀灰度发布

9.1 概念

金丝雀发布（灰度发布）是一种软件发布策略，新版本先接收小部分流量验证，稳定后再全量切换，降低发布故障风险。采取先添加再删除方式，保证Pod总量不低于期望值，更新部分Pod后暂停，确认正常再继续。

nginx-ingress canary注解优先级：header > cookie > weight。

9.2 基于header灰度

带请求头version:2的请求访问v2新版本，其余访问v1：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "version" nginx.ingress.kubernetes.io/canary-by-header-value: "2" name: myapp-v2-ingress spec: ingressClassName: nginx rules: - host: myapp.timinglee.org http: {paths: [{path: /, pathType: Prefix, backend: {service: {name: myapp-v2, port: {number: 80}}}}]} curl myapp.timinglee.org # 普通请求走v1 curl -H "version:2" myapp.timinglee.org # 带header走v2

9.3 基于权重灰度

10%流量进入v2，90%访问v1：

metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "10" nginx.ingress.kubernetes.io/canary-weight-total: "100"

测试脚本（循环100次统计分布）：

#!/bin/bash v1=0; v2=0 for (( i=0; i<100; i++)) do response=curl -s myapp.timinglee.org |grep -c v1 v1=expr $v1 + $response v2=expr $v2 + 1 - $response done echo "v1:$v1, v2:$v2" # 输出：v1:90, v2:10

10.总结

1.K8s所有内容抽象为资源，最小管理单元是Pod，生产环境禁止裸Pod，优先Deployment控制器管理，具备自愈、扩缩容、滚动更新、回滚能力；

2.三种资源管理方式：命令式（测试）、命令式配置（开发）、声明式apply（生产首选）；kubectl explain和--dry-run=client -o yaml是写yaml利器；

3.Pod YAML掌握四大字段，熟悉容器全参数；QoS等级Guaranteed（limits=requests）> Burstable > BestEffort；

4.Pod生命周期：Init容器串行执行、必须成功、不支持readiness、可延迟主容器启动；三大探针liveness杀容器重启、readiness切流量不杀容器、startup先执行禁用其他探针适合慢启动；

5.Service实现四层负载均衡，IPVS性能优于iptables；四大类型ClusterIP（默认集群内）Headless（DNS直连Pod IP，有状态应用）、NodePort（节点端口，默认30000-32767）LoadBalancer（云厂商VIP，裸金属需MetalLB）、ExternalName（CNAME转发外部域名）；

6.MetalLB为裸金属LoadBalancer分配VIP，需配置IPAddressPool地址池+L2Advertisement；

7.Ingress-nginx实现七层HTTP/HTTPS代理，由Controller+资源对象组成；高级功能包括路径转发（rewrite-target）、域名虚拟主机、TLS加密（openssl+secret tls）、BasicAuth认证（htpasswd+secret generic）、rewrite正则重定向；

8.Canary金丝雀发布先添加再删除保证Pod总量，支持header灰度（指定请求头访问新版本）和权重灰度（按比例分流），优先级header > cookie > weight。

完整链路：控制器（Deployment）→ Pod → Service（四层）→ Ingress（七层）→ 金丝雀发布，构成K8s应用从部署到对外发布的完整闭环。