Kubernetes Service、Ingress、Ingress Controller_ingress controller必须和ingress在同一个命名空间吗

Kubernetes 网络模型

K8S 是一种容器编排系统，可以方便地管理和部署容器应用程序。它支持通过四层负载和七层负载向容器集群中的应用程序提供负载均衡。

四层负载是一种基于传输层协议（例如TCP、UDP）的负载均衡方式，可以将来自客户端的请求均匀地分配给多个容器实例，以实现应用程序的高可用性和可伸缩性。K8S 中的四层负载均衡是通过内置的 kube-proxy 实现的，它可以将请求路由到不同的容器实例中，以实现负载均衡和故障转移。

七层负载是一种基于应用层协议（例如HTTP、HTTPS）的负载均衡方式，可以在不同的应用层流量之间进行智能路由，以提高应用程序的性能和可用性。K8S 中的七层负载均衡通常使用 Ingress Controller 实现，它可以监控集群中的 Ingress 资源，并自动配置负载均衡器来路由流量。 Ingress Controller 可以支持多种负载均衡算法（例如轮询、加权轮询、ip_hash等），也可以支持SSL终止、Websocket等高级功能

Kubernetes 对网络设施的基本要求

Pod 能够与所有其它节点上的 Pod 相互通信， 且不需要网络地址转译（NAT）
节点上的代理（比如：系统守护进程、kubelet）可以和节点上的所有 Pod 相互通信
1
2

Kubernetes 网络解决四方面的问题

Pod中的容器之间可以通过本地回路（loopback）相互通信
集群网络在不同 Pod 之间提供通信
Service API 允许向外暴露 Pod 中运行的应用， 以支持来自于集群外部的访问
Ingress 提供专门用于暴露 HTTP 应用程序、网站和 API 的额外功能
1
2
3
4

Service

• K8S 可以保证任意 Pod 挂掉时自动从任意节点启动一个新的Pod进行代替，以及某个Pod超负载时动态对Pod进行扩容。每当 Pod 发生变化时其 IP地址也会发生变化，且Pod只有在K8S集群内部才可以被访问，为了解决Pod发生变化导致其IP动态变化以及对外无法访问的问题，K8S引进了 Service 的概念

• K8S 使用 Service 来管理同一组标签下的 Pod ，当外界需要访问 Pod 中的容器时，只需要访问 Service 的这个虚拟 IP 和端口，由 Service 把外界的请求转发给它背后的Pod

Service暴露服务类型

1、ClusterIP（默认）

• 自动为当前Service分配虚拟IP，在不重启Service前提下该IP是不会改变的，只能在集群内部访问

2、NodePort

• 需要在K8S集群的所有 Node 节点上开放特定的端口【30000-32767】，通过（公网ip : 端口）访问Service服务。缺点：每个端口只能挂载一个Service，从安全角度讲开放更多的端口是存在一定风险的，从维护角度讲开放的端口越多维护的成本越大

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    # 默认情况下，为了方便起见，`targetPort` 被设置为与 `port` 字段相同的值。
    - port: 80
      targetPort: 80
      # 可选字段
      # 默认情况下，为了方便起见，Kubernetes 控制平面会从某个范围内分配一个端口号（默认：30000-32767）
      nodePort: 30007
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

3、LoadBalancer

• 和Nodeport相似，目的都是向外暴露一个端口，但 LoadBalancer 模式需要开发者在K8S集群外部的公有云服务器上做一个负载均衡设备（当前主流的阿里云、腾讯云、华为云、微软云等等厂商都有提供相关收费的服务），外部服务发送到公有云服务上的请求都会被负载并转发到K8S集群中LoadBalancer服务上

• 如果要在私网环境下测试LoadBalancer，必须要创建一个MetalLB， MetalLB相当于一个负载均衡器的角色

• LoadBalancer原理：外部请求首先被转发到外部LB负载设备，再通过匹配规则转发到k8s集群的任意node节点上，最终通过Service资源找到对应的pod

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  clusterIP: 10.0.171.239
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.0.2.127
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

4、ExternalName

• 通过返回 CNAME 记录和对应值，可以将服务映射到 externalName 字段的内容（例如：foo.bar.example.com），无需创建任何类型代理
  注意：需要使用 kube-dns 1.7 及以上版本或者 CoreDNS 0.0.8 及以上版本才能使用 ExternalName 类型

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com
1
2
3
4
5
6
7
8

Service代理模式

Service 创建成功后会通过 api-server 向 etcd 中写入相关配置信息，kube-proxy会监听创建好的配置信息并将最新的service配置信息转化成对应的访问规则，最终实现外网对Pod的访问。常见的service访问规则有：iptables 和 ipvs

1、iptables

kube-proxy 为 service 后端的每个Pod创建对应的iptables规则，当用户访问ClusterIP时，直接将发送到ClusterIP的请求重定向到Pod
缺点：kube-proxy 不承担四层路由转发的角色，只负责创建iptables规则，无法实现LB策略

2、ipvs（性能高于iptables）

kube-proxy 监控Pod的变化并创建相应的ipvs规则，当用户访问ClusterIP时，直接将发送到ClusterIP的请求重定向到Pod
相比于iptables，支持LB策略

3、切换到IPVS模式

• 查询当前代理模式

kubectl get pod -o wide -n kube-system | grep kube-proxy # 查新kube-proxy有关的pod
1

kubectl logs -n kube-system kube-proxy-7bst7
1

• ipvs 安装（K8S集群的所有节点安装）

# yum install -y ipvsadm.x86_64   # Centos
apt install -y ipvsadm ipset # Debian
1
2

ipvsadm -Ln # 查看ipvs模式开启状态
1

• 切换Sevice代理模式为ipvs（K8S集群的Master节点修改）

kubectl edit configmap kube-proxy -n kube-system # 编辑configmap将mode改为ipvs 
1

• 删除指定Pod

kubectl get pod -o wide -n kube-system | grep kube-proxy
1

kubectl delete pod kube-proxy-7bst7 -n kube-system # 删除pod后自动创建新的Pod
kubectl delete pod kube-proxy-9l7qr -n kube-system # 删除pod后自动创建新的Pod
kubectl delete pod kube-proxy-cqht2 -n kube-system # 删除pod后自动创建新的Pod
kubectl delete pod kube-proxy-h8znm -n kube-system # 删除pod后自动创建新的Pod
kubectl delete pod kube-proxy-l4p42 -n kube-system # 删除pod后自动创建新的Pod
kubectl delete pod kube-proxy-xlqtg -n kube-system # 删除pod后自动创建新的Pod
1
2
3
4
5
6

4、验证IPVS

# kubectl get service -o wide -n kube-system # 查询Service
#
NAME           TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                  AGE   SELECTOR
calico-typha   ClusterIP   10.96.26.184   <none>        5473/TCP                 13d   k8s-app=calico-typha
kube-dns       ClusterIP   10.96.0.2      <none>        53/UDP,53/TCP,9153/TCP   13d   k8s-app=kube-dns
1
2
3
4
5

# ipvsadm -Ln
#
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.96.0.1:443 rr
  -> 192.168.111.30:6443          Masq    1      1          0
  -> 192.168.111.31:6443          Masq    1      1          0
  -> 192.168.111.32:6443          Masq    1      1          0
  
TCP  10.96.0.2:53 rr
  -> 10.244.166.141:53            Masq    1      0          0
UDP  10.96.0.2:53 rr
  -> 10.244.166.141:53            Masq    1      0          0
  
TCP  10.96.0.2:9153 rr
  -> 10.244.166.141:9153          Masq    1      0          0
  
TCP  10.96.26.184:5473 rr
  -> 192.168.111.40:5473          Masq    1      0          0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

Service - 部署Nginx应用并对外访问

方式1：创建deployment并将其显示为Service

# kubectl create deployment <deployment名称> --image=<镜像> --replicas=<pod副本数量> -n <命名空间名称>
# kubectl expose deployment <deployment名称> --name=<Service名称> --type=<Service服务类型> --port=<service端口> --target-port=<容器端口> -n <命名空间名称>
#
# 强制删除Pod
# kubectl delete ns <命名空间名称> --force --grace-period=0 
# kubectl delete deployment <deployment名称> -n <命名空间名称> --force --grace-period=0
# kubectl delete pod <pod名称> -n <命名空间名称> --force --grace-period=0
1
2
3
4
5
6
7

kubectl create ns dev && kubectl get ns dev
kubectl create deployment nginx --image=nginx --replicas=1 -n dev
# 暴露 Deployment 为 Service 服务（将Service的8080端口转发至容器的80端口）
kubectl expose deployment nginx --name=nginx --type=NodePort --port=8080 --target-port=80 -n dev
kubectl get deployment,pods,service -n dev -o wide # 查看创建的Deployment和Pod信息
kubectl logs -n dev nginx-748c667d99-phdxv # 查看Pod创建的日志
kubectl describe -n dev pod nginx-748c667d99-phdxv # 查看Pod创建的详细信息
1
2
3
4
5
6
7

方式2：创建Service（yaml文件）

注意：基于Kubernetes Pod和工作负载文章已创建好的资源进行演示

• 创建 Service

vi service-nginx.yaml # 在线编辑文件
1

apiVersion: v1
kind: Service
metadata:
  namespace: dev
  name: nginx
  labels: 
    app: nginx
spec: 
  selector: # 标签选择器,指定对哪些deployment的Pod进行暴露
    app: nginx # deployment名称
  # type: NodePort # Service暴露服务的类型（如果需要通过公网访问请开启）
  ports:
  - protocol: TCP # 通讯协议
    # nodePort: 30000 # Node端口，结合 type: NodePort 使用
    port: 8080 # service端口
    targetPort: 80 # pod端口
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

kubectl create -f service-nginx.yaml
1

kubectl delete -f service-nginx.yaml
1

• 查看已创建的资源

kubectl get deployment,replicaSet,pods,service -n dev -o wide --show-labels
1

curl 10.244.104.10:80 # 任意Node节点，通过Pod的IP访问nginx
curl 10.244.166.157:80 # 任意Node节点，通过Pod的IP访问nginx
curl 10.96.73.217:8080 # 任意Node节点，通过Service的IP访问Nginx
1
2
3

http://192.168.111.40:30000 # 浏览器通过任意Node节点访问nginx
http://192.168.111.41:30000 # 浏览器通过任意Node节点访问nginx
http://192.168.111.42:30000 # 浏览器通过任意Node节点访问nginx
1
2
3

Ingress

ingress是k8s集群的请求入口，可以理解为对多个service的二次抽象，一般包括ingress资源对象及ingress-controller两部分

Ingress（k8s内置的资源对象）

• Ingress 是 k8s 的资源对象，用于定义外部的（HTTP 和 HTTPS）请求如何转发到 Service 服务的规则
  

ingress-controller（需要单独安装）

• ingress-controller 不是 k8s 自带的组件，只是一个统称，可以选择不同的 ingress-controller 实现对 service 的反向代理及负载均衡，常用的 ingress-controller 产品有：F5 Networks、Kong、Traefik、NGINX、HaProxy、Istio

• ingress-controller 本质是一个 pod，内部运行了 daemon 程序和反向代理程序。daemon程序通过 K8S API 不断监控集群的变化，对 ingress 定义的规则进行解析并刷新配置到反向代理程序
  

Ingress 暴露服务的方式

模式1、Deployment + NodePort 的 Service 模式

1、基于 Deployment 部署 ingress-controller 并创建对应的 Service 服务（type为NodePort），将ingress暴露在集群节点ip的特定端口上
2、一般适用于宿主机ip地址相对固定不变的场景，由于 Nodeport 暴露的端口是随机端口，一般会在前面再搭建一套负载均衡器来转发请求，NodePort方式暴露 ingress 虽然简单，但多了一层NAT，在请求量级很大时对性能会有一定影响

模式2、Deployment + LoadBalancer 的 Service 模式

1、基于 Deployment 部署 ingress-controller 并创建对应的 Service 服务（type为 LoadBalancer）
2、此模式需要将 ingress 部署在公有云，大部分公有云都会为 LoadBalancer 的 service 自动创建一个负载均衡器，通常还绑定了公网地址，只要把域名解析指向该公网地址就实现了集群服务的对外暴露

模式3、DaemonSet + HostNetwork + nodeSelector 的 Service 模式【推荐】

1、基于 DaemonSet 结合 NodeSelector 来部署 ingress-controller 到特定的 node 上，再通过 HostNetwork 把该 pod 与宿主机 node 的网络打通，通过宿主机的80/433端口访问服务，此时的ingress-controller所在的node节点就类似传统架构的边缘节点（房入口的nginx服务器）
2、该方式相对NodePort模式的性能更好，缺点：由于直接利用宿主机节点的网络和端口，一个node节点只能部署一个ingress-controller，适合大并发的生产环境使用

Ingress 安装

注意：不同的暴露服务方式对应的安装方式是不一样的
安装教程

【模式3】Ingress - 部署 httpd 应用并对外访问

创建 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: dev
  name: httpd
  labels:
    app: httpd
spec: 
  selector: # Pod标签选择器，指定当前控制器管理哪些Pod
    matchLabels:
      app: httpd
    matchExpressions:
      - { key: app, operator: In, values: [httpd] }
  replicas: 1 # 默认Pod副本数量
  template: 
      metadata:
        labels: 
          app: httpd
      spec:
        #hostNetwork: true # 开启后，可以直接通过宿主机的80/433端口访问
        nodeName: node2 # 将Pod调度到Node2工作节点
        containers:
        - name: httpd
          image: httpd
          imagePullPolicy: IfNotPresent
          ports: 
          - name: httpd 
            protocol: TCP
            containerPort: 80 # Pod下的容器端口
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

创建 Service

apiVersion: v1
kind: Service
metadata:
  namespace: dev
  name: httpd
spec: 
  selector: # deployment标签选择器,指定当前Service管理哪些控制器
    app: httpd
  #type: NodePort # Service暴露服务的类型,默认ClusterIP类型
  ports:
  - protocol: TCP # 通讯协议
    #nodePort: 30000 # 集群上所有Node节点端口
    port: 8080 # Service端口
    targetPort: 80 # Pod端口
1
2
3
4
5
6
7
8
9
10
11
12
13
14

创建 Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: dev
  name: ingress-httpd-http
  annotations:
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
    - host: www.lixing40.com # 通过Node1节点访问，默认Ingress-Nginx-Controller部署在Node1节点
      http:
        paths:
          - pathType: Prefix
            path: /httpd
            backend:
              service:
                name: httpd # Service名称
                port:
                  number: 8080 # Service端口
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

创建Ingress过程中如果报如下错误：
“Error from server (InternalError): error when creating “ingress-srv.yaml”: Internal error occurred: failed calling webhook “validate.nginx.ingress.kubernetes.io”: Post “https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1/ingresses?timeout=10s”: dial tcp 10.102.20.133:443: connect: connection refused
#
原因：
删除nginx-ingress不彻底（没有删除ValidatingWebhookConfiguration ingress-nginx-admission），当我再次安装nginx-ingress之后，创建自定义的ingress就会报这个错误
#
请按照如下操作：
kubectl get ValidatingWebhookConfiguration
kubectl delete -A ValidatingWebhookConfiguration ingress-nginx-admission
1
2
3
4
5
6
7
8
9

查看dev命名空间下的资源对象

kubectl get deployment,replicaSet,pods,service,ingress -n dev -o wide
1

• 任意工作节点上通过Pod访问httpd服务

curl 10.244.104.14
1

• 任意工作节点上通过Service访问httpd服务

curl 10.96.170.140:8080
1

查看ingress-nginx命名空间下的资源对象

kubectl get deployment,replicaSet,pods,service,ingress -n ingress-nginx -o wide
1

[HTTP]各节点通过域名访问httpd服务

• 修改 Node1节点的host文件

vi /etc/hosts # 编辑Host文件,添加当前节点的ip和自定义域名
	192.168.111.40 www.lixing40.com
1
2

# 在Node1节点上访问：
curl http://www.lixing40.com/httpd
1
2

• 修改win11本地的host文件

# k8s主节点ip    自定义域名
192.168.111.40 www.lixing40.com
1
2

# 在win11本地浏览器访问
http://www.lixing40.com/httpd
1
2

[HTTPS]各节点通过域名访问httpd服务

对于ingress TSL的基本要求是有TSL/SSL证书，每个TLS证书都有一个过期日期，必须在证书过期前跟新证书，一般我们可以通过下面几种方法获得证书：
1、自签名的证书：用我们自己的CA（证书颁发机构）来创建和签名TLS证书。这种方法非常适合开发环境，你可以把根证书分享给团队，方便浏览器信任自签名的证书。参考这篇博客create self-signed certificate来创建你自己的证书
2、购买一个TLS证书：从浏览器和操作系统信任的知名CA（证书颁发机构）购买TLS证书
3、使用Letsencrpt证书：Letsencrpt是一家非盈利的可信证书颁发机构，他们提供免费的TLS证书
1
2
3
4

SSL是由ingress controller来处理的，而不是ingress。把TLS证书作为kubernetes sercet添加到ingress里面时，ingress controller就能获取到它，并使其变为自己的配置信息
1

• 创建kubernetes TLS sercet(Master1节点操作)

# 创建证书文件夹
mkdir -p /etc/certs/ingress
1
2

# 生成TLS证书
# openssl req -x509 -nodes -days <证书有效天数> -newkey rsa:2048 -keyout <tls.key保存路径> -out <tls.crt保存路径> -subj "/CN=<名称>/O=<名称>"
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/certs/ingress/tls.key -out /etc/certs/ingress/tls.crt -subj "/CN=www.lixing40.com/O=www.lixing40.com"
1
2
3

# 根据生成的TLS证书文件创建集群的secret
# kubectl create secret tls <名称> --key <tls.key路径> --cert <tls.crt路径> -n <命名空间>
kubectl create secret tls tls-ingress-httpd --key /etc/certs/ingress/tls.key --cert /etc/certs/ingress/tls.crt -n dev
1
2
3

# 查看新建TLS证书配置
kubectl get secret tls-ingress-httpd -n dev
1
2

• 创建 Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: dev
  name: ingress-httpd-https
  annotations:
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - www.lixing40.com
    secretName: tls-ingress-httpd # 根据生成的TLS证书文件创建集群的secret
  rules:
    - host: www.lixing40.com # 通过Node1节点访问，默认Ingress-Nginx-Controller部署在Node1节点
      http:
        paths:
          - pathType: Prefix
            path: /httpd
            backend:
              service:
                name: httpd # Service名称
                port:
                  number: 8080 # Service端口
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# 在win11本地浏览器访问
http://www.lixing40.com/httpd
1
2