k8s运维-service与ingress（3）

前言：

        此章节讲解k8s集群是如何实现负载均衡与反向代理的，最后会有一个实战项目作为例子，来带兄弟们实操体验其作用，但相信很多兄弟都还会有些疑问，在真正工作环境当中，它有哪些应用场景呢？，举个实际例子，如现在你入职的一家公司，现在业务还未使用k8s，现需要你将这些传统跑在docker上的服务更新到k8s集群当中，你应该怎么操作，如果你理解了此章节内容，并且将最后一个实战项目独立实现了出来，一通百通，那工作遇到这种情况也能轻松应对，无非就是服务不太一样，其余大差不差（博主现在公司就是半docker，半k8s，贼离谱，但没办法，谁叫咱是个打工人呢≧ ﹏ ≦）

service

        首先，我们一定要理解其理论，以及工作原理，这些是最重要的，无论是你后续实操还是排错，所有不要觉得字太多就不想看了，要不然后续实验，错在哪你都不知道！！！

什么是service？（重点）

        Service 是一种抽象资源，用于定义一组逻辑上相关的 Pod 的访问策略，并为这些 Pod 提供一个稳定的网络端点（通常是 IP 地址和 DNS 名称）。由于 Pod 是动态创建和销毁的（例如因扩缩容、节点故障等），其 IP 地址会不断变化，而 Service 通过标签选择器（Label Selector）动态关联目标 Pod，解决了客户端直接访问 Pod 带来的不稳定问题。

为什么需要 Service (SVC)？（重点）

要理解 SVC 的作用，首先要明白没有它时会出现的问题：

Service 就是为了解决这些问题而生的。

Service 的核心功能与工作原理（重点）

1. 提供稳定的访问点（VIP 和 DNS）

• 当你创建一个 Service 时，Kubernetes 会为它分配一个固定的虚拟 IP（VIP，ClusterIP）。这个 IP 在 Service 的整个生命周期内都不会改变（除非你删除重建）。

• 同时，Kubernetes 的 DNS 服务（CoreDNS） 会为这个 Service 创建一个唯一的 DNS 记录，格式为：<service-name>.<namespace>.svc.cluster.local。

• 集群内的其他应用只需要访问这个固定的 VIP 或 DNS 名称，就可以找到后端的所有 Pod，完全不需要关心具体是哪些 Pod 在提供服务、它们的 IP 是什么。

2. 负载均衡

• Service 通过 Label Selector（标签选择器） 来识别和管理一组 Pod。

• 它会自动将发送到 Service VIP 的请求，均匀地分发到所有匹配标签的后端 Pod 上。

3. 服务发现

• 如上所述，通过固定的 DNS 名称，集群内的应用可以轻松地发现并依赖其他服务，无需硬编码 IP 地址。

工作原理：

Service 的主要类型（Type）

Service 有几种类型，决定了它的网络暴露范围：

模板案例：

案例1：使用clusterip，使得集群内部pod实现负载均衡

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-app
spec:
replicas: 3
selector:
matchLabels:
app: nginx-app
template:
metadata:
labels:
app: nginx-app # 这个标签很重要！
spec:
containers:
– name: nginx
image: nginx
ports:
– name: http #此处名称可以与service中的targetport对应
containerPort: 80
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "hostname -I > /usr/share/nginx/html/index.html"]

ClusterIP

# service.yaml
apiVersion: v1
kind: Service # 类型是 Service
metadata:
name: my-svc # Service 的名称
spec:
selector:
app: my-app # 通过此选择器找到要管理的 Pod（必须与 Deployment 中的 Pod 标签匹配）
ports:
– protocol: TCP
port: 80 # Service 自身的端口
targetPort: http # 后端 Pod 的端口（与 containerPort 一致）或端口名称
type: ClusterIP # 不写的话默认就是 ClusterIP

#运行yaml文件
root@k8s-master:~/k8s/service# kubectl apply -f nginx-dp.yaml
deployment.apps/nginx-app created
root@k8s-master:~/k8s/service# kubectl apply -f nginx-svc.yaml
service/nginx-svc configured

#如下endpoint参数如果出现对于pod id即配置成功！！！
root@k8s-master:~/k8s/service# kubectl get svc -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 16d <none>
nginx-svc ClusterIP 10.106.37.209 <none> 80/TCP 5d21h app=nginx-app

root@k8s-master:~/k8s/service# kubectl describe svc nginx-svc
Name: nginx-svc
Namespace: default
Labels: <none>
Annotations: <none>
Selector: app=nginx-app
Type: ClusterIP
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.106.37.209
IPs: 10.106.37.209
Port: <unset> 80/TCP
TargetPort: http/TCP
Endpoints: 10.244.3.35:80,10.244.1.37:80,10.244.3.34:80
Session Affinity: None
Internal Traffic Policy: Cluster
Events: <none>

（我靠，这编辑代码里边连个加粗都没有，太拉跨了！！！）

错误分析：

        嘿，居然有问题，上述pod并未正常启动，READY就绪为0，很好，以这个错误为例，我们来分析一下问题

1. 首先随便选择一个pod查看其详细信息（注意：此命令是k8s排查必备命令，一定要熟悉）
kubectl describe pod xxxx

2. 查看event事件报错原因，一般这个时候基本可以定位到是什么错误导致的了

root@k8s-master:~/k8s/service# kubectl describe pod nginx-app-5668c54d76-5mqkv
Name: nginx-app-5668c54d76-5mqkv
Namespace: default
Priority: 0
Service Account: default
Node: k8s-worker-01/192.168.44.201
Start Time: Sun, 01 Mar 2026 08:45:07 +0000
Labels: app=nginx-app
pod-template-hash=5668c54d76
Annotations: <none>
Status: Running
IP: 10.244.1.37
IPs:
IP: 10.244.1.37
Controlled By: ReplicaSet/nginx-app-5668c54d76
Containers:
nginx:
Container ID: containerd://21e7d51f76ab3f74a3a583d0f4d61166db549fd94f77dde8d43d3905f1a5af09
Image: nginx
Image ID: docker.io/library/nginx@sha256:0236ee02dcbce00b9bd83e0f5fbc51069e7e1161bd59d99885b3ae1734f3392e
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Sun, 01 Mar 2026 08:58:39 +0000
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-dnv78 (ro)
Conditions:
Type Status
PodReadyToStartContainers True
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kube-api-access-dnv78:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
—- —— —- —- ——-
Normal Scheduled 16m default-scheduler Successfully assigned default/nginx-app-5668c54d76-5mqkv to k8s-worker-01
Normal Pulling 14m (x4 over 16m) kubelet Pulling image "nginx"
Warning Failed 13m (x4 over 16m) kubelet Failed to pull image "nginx": failed to pull and unpack image "docker.io/library/nginx:latest": failed to resolve image: failed to do request: Head "https://registry-1.docker.io/v2/library/nginx/manifests/latest": dial tcp 208.43.170.231:443: connect: connection refused
Warning Failed 13m (x4 over 16m) kubelet Error: ErrImagePull
Warning Failed 13m (x6 over 16m) kubelet Error: ImagePullBackOff
Normal BackOff 6m32s (x32 over 16m) kubelet Back-off pulling image "nginx"

        这是由于我初始化集群时并未指定镜像下载地址，所以现在访问的是默认下载地址，但是国内是不可以正常访问外网地址，此时两个方法，一是修改为国内镜像地址，二配置魔法代理

这边我给兄弟们整理了一个不需要翻墙的方法。如下复制粘贴即可：

sed -i.bak '/\\[plugins\\."io\\.containerd\\.cri\\.v1\\.images"\\.registry\\]/,/^\\[/ s/^\\([[:space:]]*config_path =\\).*/\\1 "\\/etc\\/containerd\\/certs.d"/' /etc/containerd/config.toml

mkdir -p /etc/containerd/certs.d/docker.io

cat >> /etc/containerd/certs.d/docker.io/hosts.toml < EOF
server = "https://registry-1.docker.io"

[host."https://替换为你自己的阿里云镜像地址，或者直接注释使用下边地址，就是拉取有些慢"]
capabilities = ["pull", "resolve"]

# 1. 上海交通大学镜像源（相对稳定）
[host."https://docker.mirrors.sjtug.sjtu.edu.cn"]
capabilities = ["pull", "resolve"]

# 2. DaoCloud 镜像源（另一个常用公共源）
[host."https://docker.m.daocloud.io"]
capabilities = ["pull", "resolve"]

# 3. 中科大镜像源
[host."https://docker.mirrors.ustc.edu.cn"]
capabilities = ["pull", "resolve"]

# 4. 把之前出现429的源往后放，作为备选
[host."https://docker.1panel.top"]
capabilities = ["pull", "resolve"]
EOF

测试：

        如下访问svc可负载均衡到各个pod即实验成功！！！

root@k8s-master:~/k8s/service# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-app-5668c54d76-5mqkv 1/1 Running 0 68m 10.244.1.37 k8s-worker-01 <none> <none>
nginx-app-5668c54d76-9qkw8 1/1 Running 0 68m 10.244.3.35 k8s-worker-02 <none> <none>
nginx-app-5668c54d76-stfxk 1/1 Running 0 68m 10.244.3.34 k8s-worker-02 <none> <none>
root@k8s-master:~/k8s/service# kubectl exec -it nginx-app-5668c54d76-5mqkv — /bin/bash
root@nginx-app-5668c54d76-5mqkv:/# curl nginx-svc
10.244.1.37
root@nginx-app-5668c54d76-5mqkv:/# curl nginx-svc
10.244.3.34
root@nginx-app-5668c54d76-5mqkv:/# curl nginx-svc
10.244.3.34
root@nginx-app-5668c54d76-5mqkv:/# curl nginx-svc
10.244.3.35

疑问分析（重点）

        上述实验成功执行后，兄弟们是不是有个疑问，为什么我在pod里边直接访问service名称，可以直接访问到对应pod呢，一个简单的curl命令又进行了哪些操作呢，下边让我带兄弟们来分析一下（注：此处以理解为主，这是一个比较重要的知识点，后续部署项目都会用到！！！）

1. 为什么要直接访问service名称，IP不行吗？

        不行，为什么？，如果我们在跑一个项目时将service的IP固定死了以后，如果后续我们需要更新服务，不小心将svc也出现apply了，此时svc会重新创建一个新pod，那么ip地址也很显然也是会重新创建的，这个时候代码里边的ip地址与实际ip对不上，可能导致你的整个网站都出不来了

2. 凭什么我可以直接访问service地址，而我的宿主机上却不行

#此时是在pod当中
root@nginx-app-5668c54d76-5mqkv:/# curl nginx-svc
10.244.1.37
root@nginx-app-5668c54d76-5mqkv:/# exit
exit
#推出以后
root@k8s-master:~/k8s/service# curl nginx-svc
curl: (6) Could not resolve host: nginx-svc

第一步：查看pod当中的dns服务

root@nginx-app-5668c54d76-5mqkv:/# cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5

上述dns服务器为10.96.0.10，此为k8s默认的dns服务器，在创建一个pod时会自动写入

第二步：在集群当中查找10.96.0.10，理解改dns在集群当中具体是个什么东西

root@k8s-master:~/k8s/service# kubectl get svc -A -o wide
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
default kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 16d <none>
default nginx-svc ClusterIP 10.106.37.209 <none> 80/TCP 6d app=nginx-app
kube-system kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 16d k8s-app=kube-dns
kube-system metrics-server ClusterIP 10.109.176.205 <none> 443/TCP 6d7h k8s-app=metrics-server

#查看endpoint端点对应ip
root@k8s-master:~/k8s/service# kubectl describe svc kube-dns -n kube-system
Name: kube-dns
Namespace: kube-system
Labels: k8s-app=kube-dns
kubernetes.io/cluster-service=true
kubernetes.io/name=CoreDNS
Annotations: prometheus.io/port: 9153
prometheus.io/scrape: true
Selector: k8s-app=kube-dns
Type: ClusterIP
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.96.0.10
IPs: 10.96.0.10
Port: dns 53/UDP
TargetPort: 53/UDP
Endpoints: 10.244.0.12:53,10.244.0.13:53
Port: dns-tcp 53/TCP
TargetPort: 53/TCP
Endpoints: 10.244.0.12:53,10.244.0.13:53
Port: metrics 9153/TCP
TargetPort: 9153/TCP
Endpoints: 10.244.0.12:9153,10.244.0.13:9153
Session Affinity: None
Internal Traffic Policy: Cluster
Events: <none>

此时我们会发现它是一个名为kube-dns的service，很好，那我们接着查看它又是绑定的哪几个pod

第三步：查找对应pod，在集群当中扮演的是什么角色

root@k8s-master:~/k8s/service# kubectl get pod -A -o wide |grep 10.244.0
kube-system coredns-7c65d6cfc9-2g227 1/1 Running 4 (3h19m ago) 16d 10.244.0.13 k8s-master <none> <none>
kube-system coredns-7c65d6cfc9-cmphb 1/1 Running 4 (3h19m ago) 16d 10.244.0.12 k8s-master <none> <none>

查找出如上coredns服务，而coredns是k8s集群当中专门用来进行域名解析的，可以把它当中为一个集群自带的dns服务器，现在结果很明显了，为什么可以访问service名称，因为coredns服务给svc的名称与ip配置了域名解析服务，而宿主机上是没有这个域名服务器的，所有宿主机上是不可访问的

如下流程图：

下边是我使用ai给兄弟们总结的流程图，兄弟们都可以参考参考

Kubernetes Service (IPVS模式) 网络不通排查指南

排查流程

namespace

什么是namespace？

在 Kubernetes（k8s）中，namespace 是一个逻辑隔离的概念，用于将同一个物理集群划分为多个虚拟集群。它主要用来：

• 资源隔离：不同 namespace 中的资源（如 Pod、Service、Deployment）可以重名。

• 权限控制：通过 RBAC（基于角色的访问控制），可以为不同 namespace 的用户授予不同的权限。

• 资源配额：可以为 namespace 设置资源配额（如 CPU、内存上限），防止某个团队耗尽集群资源。

• 多环境管理：常见用法是创建 dev、test、prod 等 namespace，分别部署不同环境的应用。

举例：你在执行 kubectl get pods -n kube-system 时，就是在查看 kube-system 这个 namespace 下的 Pod（通常是 Kubernetes 系统组件）。

namespace使用

#创建一个namespace
kubectl create namespace nginx

#指定命名空间创建资源
cat >> svc.yaml < EOF
apiVersion: v1
kind: Service # 类型是 Service
metadata:
name: my-svc # Service 的名称
namespace: nginx
spec:
selector:
app: my-app # 通过此选择器找到要管理的 Pod（必须与 Deployment 中的 Pod 标签匹配）
ports:
– protocol: TCP
port: 80 # Service 自身的端口
targetPort: http # 后端 Pod 的端口（与 containerPort 一致）或端口名称
nodePort: 30000 #端口范围30000~32000
type: NodePort
EOF

#查看指定命名空间内资源
kubectl get svc my-svc -n nginx

总结：

1.命令空间也是一种资源类型
2.不同的命令空间资源互相隔离
3.跨命名空间Service之间的通讯需要指定Service所属的命名空间
如：curl my-svc.nginx
4.删除命名空间会自动将这个命名空间下所有的资源全部删除

ingress

Ingress 是什么？

        你可以把 Ingress 理解为 Kubernetes 集群的智能路由网关或七层负载均衡器（个人理解为等同于nginx）

        它的核心职责是管理从集群外部到集群内部服务的 HTTP 和 HTTPS 路由。它就像是整个集群的“门户”或“前台接待”，所有来自外部的请求都先到达它，然后由它根据预定义的规则将请求转发到对应的后端服务。

为什么需要 Ingress？解决了什么问题？

在理解 Ingress 的作用之前，我们先看看没有它时，暴露服务的方式及其局限性：

Ingress 完美地解决了上述问题：

• 一个入口：只需一个公网 IP 地址（通过一个 LoadBalancer 类型的 Service 提供），所有外部流量都通过它进入。

• 基于规则的路由：可以根据请求的主机名（域名） 和URL 路径，将流量路由到不同的后端服务。

• 降低成本：只需要一个负载均衡器，而不是每个服务一个。

• 集中管理：提供统一的入口点，便于配置 SSL 终止、认证、路由等规则。

ingress安装部署

        由于k8s只提供ingress执行，但是没有该功能，所有我们需要额外安装它，ingress控制器有很多，此处我选择安装的是ingress-nginx

1. 版本选择

        对照下述链接上的ingress和k8s版本要求，选择合适版本，或直接查看下图，这里我们直接选择最新的即可

        https://github.com/kubernetes/ingress-nginx

2. 官网下载对应版本的yaml文件，并修改镜像为国内源

curl -LO https://raw.githubusercontent.com/kubernetes/ingress-nginx/refs/heads/release-1.14/deploy/static/provider/kind/deploy.yaml

#如下运行成功！！！

root@k8s-master:~/k8s/ingress# kubectl get pod -n ingress-nginx
NAME READY STATUS RESTARTS AGE
ingress-nginx-controller-69cfc98579-hgbjd 1/1 Running 0 84s

如若不能访问外网，直接拷贝下述文件执行即可（连个文件都上传不了，真破！！！）

apiVersion: v1
kind: Namespace
metadata:
labels:
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
name: ingress-nginx
—
apiVersion: v1
automountServiceAccountToken: true
kind: ServiceAccount
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx
namespace: ingress-nginx
—
apiVersion: v1
automountServiceAccountToken: true
kind: ServiceAccount
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx-admission
namespace: ingress-nginx
—
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx
namespace: ingress-nginx
rules:
– apiGroups:
– ""
resources:
– namespaces
verbs:
– get
– apiGroups:
– ""
resources:
– configmaps
– pods
– secrets
– endpoints
verbs:
– get
– list
– watch
– apiGroups:
– ""
resources:
– services
verbs:
– get
– list
– watch
– apiGroups:
– networking.k8s.io
resources:
– ingresses
verbs:
– get
– list
– watch
– apiGroups:
– networking.k8s.io
resources:
– ingresses/status
verbs:
– update
– apiGroups:
– networking.k8s.io
resources:
– ingressclasses
verbs:
– get
– list
– watch
– apiGroups:
– coordination.k8s.io
resourceNames:
– ingress-nginx-leader
resources:
– leases
verbs:
– get
– update
– apiGroups:
– coordination.k8s.io
resources:
– leases
verbs:
– create
– apiGroups:
– ""
resources:
– events
verbs:
– create
– patch
– apiGroups:
– discovery.k8s.io
resources:
– endpointslices
verbs:
– list
– watch
– get
—
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx-admission
namespace: ingress-nginx
rules:
– apiGroups:
– ""
resources:
– secrets
verbs:
– get
– create
—
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx
rules:
– apiGroups:
– ""
resources:
– configmaps
– endpoints
– nodes
– pods
– secrets
– namespaces
verbs:
– list
– watch
– apiGroups:
– coordination.k8s.io
resources:
– leases
verbs:
– list
– watch
– apiGroups:
– ""
resources:
– nodes
verbs:
– get
– apiGroups:
– ""
resources:
– services
verbs:
– get
– list
– watch
– apiGroups:
– networking.k8s.io
resources:
– ingresses
verbs:
– get
– list
– watch
– apiGroups:
– ""
resources:
– events
verbs:
– create
– patch
– apiGroups:
– networking.k8s.io
resources:
– ingresses/status
verbs:
– update
– apiGroups:
– networking.k8s.io
resources:
– ingressclasses
verbs:
– get
– list
– watch
– apiGroups:
– discovery.k8s.io
resources:
– endpointslices
verbs:
– list
– watch
– get
—
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx-admission
rules:
– apiGroups:
– admissionregistration.k8s.io
resources:
– validatingwebhookconfigurations
verbs:
– get
– update
—
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx
namespace: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: ingress-nginx
subjects:
– kind: ServiceAccount
name: ingress-nginx
namespace: ingress-nginx
—
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx-admission
namespace: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: ingress-nginx-admission
subjects:
– kind: ServiceAccount
name: ingress-nginx-admission
namespace: ingress-nginx
—
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: ingress-nginx
subjects:
– kind: ServiceAccount
name: ingress-nginx
namespace: ingress-nginx
—
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx-admission
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: ingress-nginx-admission
subjects:
– kind: ServiceAccount
name: ingress-nginx-admission
namespace: ingress-nginx
—
apiVersion: v1
data: null
kind: ConfigMap
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx-controller
namespace: ingress-nginx
—
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx-controller
namespace: ingress-nginx
spec:
ipFamilies:
– IPv4
ipFamilyPolicy: SingleStack
ports:
– appProtocol: http
name: http
port: 80
protocol: TCP
targetPort: http
– appProtocol: https
name: https
port: 443
protocol: TCP
targetPort: https
selector:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
type: LoadBalancer
—
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx-controller-admission
namespace: ingress-nginx
spec:
ports:
– appProtocol: https
name: https-webhook
port: 443
targetPort: webhook
selector:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
type: ClusterIP
—
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx-controller
namespace: ingress-nginx
spec:
minReadySeconds: 0
revisionHistoryLimit: 10
selector:
matchLabels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
strategy:
rollingUpdate:
maxUnavailable: 1
type: RollingUpdate
template:
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
spec:
automountServiceAccountToken: true
containers:
– args:
– /nginx-ingress-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
– –watch-ingress-without-class=true
– –publish-status-address=localhost
env:
– name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
– name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
– name: LD_PRELOAD
value: /usr/local/lib/libmimalloc.so
image: registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:v1.14.3
imagePullPolicy: IfNotPresent
lifecycle:
preStop:
exec:
command:
– /wait-shutdown
livenessProbe:
failureThreshold: 5
httpGet:
path: /healthz
port: 10254
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
name: controller
ports:
– containerPort: 80
hostPort: 80
name: http
protocol: TCP
– containerPort: 443
hostPort: 443
name: https
protocol: TCP
– containerPort: 8443
name: webhook
protocol: TCP
readinessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 10254
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
resources:
requests:
cpu: 100m
memory: 90Mi
securityContext:
allowPrivilegeEscalation: false
capabilities:
add:
– NET_BIND_SERVICE
drop:
– ALL
readOnlyRootFilesystem: false
runAsGroup: 82
runAsNonRoot: true
runAsUser: 101
seccompProfile:
type: RuntimeDefault
volumeMounts:
– mountPath: /usr/local/certificates/
name: webhook-cert
readOnly: true
dnsPolicy: ClusterFirst
nodeSelector:
kubernetes.io/os: linux
serviceAccountName: ingress-nginx
terminationGracePeriodSeconds: 0
tolerations:
– effect: NoSchedule
key: node-role.kubernetes.io/master
operator: Equal
– effect: NoSchedule
key: node-role.kubernetes.io/control-plane
operator: Equal
volumes:
– name: webhook-cert
secret:
secretName: ingress-nginx-admission
—
apiVersion: batch/v1
kind: Job
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx-admission-create
namespace: ingress-nginx
spec:
template:
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx-admission-create
spec:
automountServiceAccountToken: true
containers:
– args:
– create
– –host=ingress-nginx-controller-admission,ingress-nginx-controller-admission.$(POD_NAMESPACE).svc
– –namespace=$(POD_NAMESPACE)
– –secret-name=ingress-nginx-admission
env:
– name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.6.7
imagePullPolicy: IfNotPresent
name: create
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
– ALL
readOnlyRootFilesystem: true
runAsGroup: 65532
runAsNonRoot: true
runAsUser: 65532
seccompProfile:
type: RuntimeDefault
nodeSelector:
kubernetes.io/os: linux
restartPolicy: OnFailure
serviceAccountName: ingress-nginx-admission
ttlSecondsAfterFinished: 0
—
apiVersion: batch/v1
kind: Job
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx-admission-patch
namespace: ingress-nginx
spec:
template:
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx-admission-patch
spec:
automountServiceAccountToken: true
containers:
– args:
– patch
– –webhook-name=ingress-nginx-admission
– –namespace=$(POD_NAMESPACE)
– –patch-mutating=false
– –secret-name=ingress-nginx-admission
– –patch-failure-policy=Fail
env:
– name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
image: registry.cn-hangzhou.aliyuncs.com/google_containers/kube-webhook-certgen:v1.6.7
imagePullPolicy: IfNotPresent
name: patch
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
– ALL
readOnlyRootFilesystem: true
runAsGroup: 65532
runAsNonRoot: true
runAsUser: 65532
seccompProfile:
type: RuntimeDefault
nodeSelector:
kubernetes.io/os: linux
restartPolicy: OnFailure
serviceAccountName: ingress-nginx-admission
ttlSecondsAfterFinished: 0
—
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: nginx
spec:
controller: k8s.io/ingress-nginx
—
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.14.3
name: ingress-nginx-admission
webhooks:
– admissionReviewVersions:
– v1
clientConfig:
service:
name: ingress-nginx-controller-admission
namespace: ingress-nginx
path: /networking/v1/ingresses
port: 443
failurePolicy: Fail
matchPolicy: Equivalent
name: validate.nginx.ingress.kubernetes.io
rules:
– apiGroups:
– networking.k8s.io
apiVersions:
– v1
operations:
– CREATE
– UPDATE
resources:
– ingresses
sideEffects: None

资源配置清单

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nginx-ingress
namespace: nginx-dp
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx
rules:
– host: "nginx.local"
http:
paths:
– path: /
pathType: Prefix
backend:
service:
name: nginx-svc
port:
number: 80

配置解析（此处我就直接问ai了，感觉比我自己总结得还好）

1. ingressClassName

• ingressClassName: nginx
  指定要使用的 Ingress 控制器。集群中必须存在一个名为 nginx 的 IngressClass 资源，且该资源指向一个具体的 Ingress 控制器（如 NGINX Ingress Controller）。这相当于告诉集群使用哪个控制器来处理这个 Ingress。

2. rules（规则列表）

• rules：定义一组路由规则，可以包含多个 host（域名）规则。

2.1 host

• host: "nginx.local"
  指定匹配的域名。只有 HTTP 请求头中 Host 字段为 nginx.local 的请求才会应用这条规则。如果省略 host，则规则适用于所有域名（即默认后端）。

2.2 http

• http：定义 HTTP 协议下的路由规则。

2.2.1 paths（路径规则）

• paths：一个路径匹配规则列表，按顺序匹配。

  • path: /
    要匹配的路径。

  • pathType: Prefix
    路径匹配类型。Prefix 表示前缀匹配，即只要请求路径以 / 开头（本例中所有路径都以 / 开头）就会命中该规则。另一种常用类型是 Exact，要求完全匹配。

  • backend：定义匹配成功后流量要转发到的后端服务。

    • service：指定 Kubernetes Service 作为后端。

      • name: nginx-svc
        后端服务的名称，必须与 Ingress 在同一命名空间下。

      • port:

        • number: 80
          后端服务的端口号，流量将被转发到该端口。

实战项目

1. xzs考试系统部署

2. wordpress博客系统部署