K8s集群：命名空间（Namespace）

Published on 2022-08-03

K8s集群：Pod 与 Deployment

一、k8s - Pod 介绍

创建第一个 Pod 资源

Pod 可以理解为一组容器，是 K8s 最小的调度单位。首先我们创建第一个 Pod 资源来运行我们的项目。

# cat datarc-test-pod.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: datarc
  
---

apiVersion: v1
kind: Pod
metadata:
  namespace: datarc
  name: datarc-test-pod
  labels:
    app: nginx
spec:
  containers:
  - name: app1
    image: nginx:1.13
    ports:
      - containerPort: 80
      
# 创建
kubectl apply -f datarc-test-pod.yaml

二、Deployment 介绍

创建第一个 Deployment

因为 Pod 是最小的调度单位，我们通常会创建 Deployment 对象，通过 Deployment 对象来进行管理 Pod。

1
2

问：为什么一般不创建 Pod 对象呢？
答：因为创建的 pod 对象，如果挂掉是不会被 k8s 感知和重启的，创建 Deployment 对象可以管理多组 pod 对象，如果 pod 挂掉，Deployment 对象则会重新拷贝一个 pod 的副本出来，所以我们需要创建 Deployment 对象而不是创建 Pod 对象。

我们通过创建 YAML 的描述文件，k8s 根据这个 YAML来创建相对应的资源对象。

# cat datarc-deployment-test1.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: datarc
  
---

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: datarc
  name: datarc-test-pod
  labels:
    app: datarc
spec:
  replicas: 2
  selector:
    matchLabels:
      app: datarc
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: datarc
    spec:
      containers:
      - image: nginx:1.13
        name: datarc-1
        resources: {}
status: {}

# 创建
kubectl apply -f datarc-deployment-test1.yaml

相关命令：

查看 Deployment

kubectl get deployments -n
查看 Pod

kubectl get pods -n

kubectl describe pods -n datarc
查看 logs 日志

kubectl logs -n
进入 exec

kubectl exec – curl -s

三、Service 暴露服务

是运行 Pod Ip 是 Docker 网桥的 IP 地址段进行分配的，通常是一个虚拟的二层网络，外部网络并没有办法访问，并且，Pod Ip是随时会变的，不是固定的，k8s 引入了 Service 的概念，通过 Service 管理这些 Pod，Service 创建后的 Service IP 是固定的。但是 Service IP(Cluster IP) 是一个虚拟的 IP ,由 Kubernetes 管理和分配 IP 地址，外部网络无法访问。k8s 有三种方式暴露 Service 给外部网络访问。

问：为什么Pod的IP会变化？
答：Kubernetes 具有强大的副本控制能力，能保证在任意副本（Pod）挂掉时自动从其他机器启动一个新的，所以说，这个 Pod 可能在任何时刻出现在任何节点上，也可能在任何时刻死在任何节点上；那么自然随着 Pod 的创建和销毁，Pod IP 肯定会动态变化

问：如何解决 Pod 的 IP 会变的问题？
答：当 Pod 宕机后重新生成时，其 IP 等状态信息可能会变动，Service 会根据 Pod 的 Label 对这些状态信息进行监控和变更，保证上游服务不受 Pod 的变动而影响。

问：什么是 Service ？
答：Kubernetes Service 定义了：Service 是一种可以访问 Pod 逻辑分组的策略， Service 通常是通过 Label Selector访问 Pod 组; 
   Service 能够提供负载均衡的能力，但是在使用上有些限制：只提供 4 层负载均衡能力，而没有 7 层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上 4 层负载均衡是不支持的。

Service 有以下几种类型：

ClusterIp ：默认类型，自动分配一个仅 ClusterIP 内部可以访问的虚拟服务 IP，集群内部有效，适用于集群内多个 service 之间互相通讯；

imges

NodePort：在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过: NodePort 来访问该服务，外层配合 Nginx 对用户提供访问。

LoadBalane：在 NodePort 的基础上，借助 Cloud Provider 创建一个外部负载均衡器，并将请求转发到 NodePort

ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 Kubernetes 1.7或更高版本的kube-dns才支持。

Service 是怎么运行的：

客户端访问节点时通过 iptables 实现
iptables 规则是通过 kube-proxy 写入
apiserver 通过监控 kube-proxy 去进行对服务和端点的监控
kube-proxy 通过 pod 的标签（ lables）去判断这个断点信息是否写入到 Endpoints 里

暴露服务的三种方式：

ClusterIP

ClusterIP 主要在每个 node 节点使用 iptables ，将发向 ClusterIP 对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应 pod 的地址和端口，进而把数据转发给对应的 pod 的地址和端口。
NodePort
将服务的类型设置成 NodePort 每个集群节点都会在节点上打开一个端口，对于 NodePort 服务，每个集群节点在节点本身（因此得名叫 NodePort )上打开一个端口，并将在该端口上接收到的流量重定向到基础服务。该服务仅在内部集群 IP 和端口上才可访间，但也可通过所有节点上的专用端口访问。
LoadBalane

将服务的类型设置成 LoadBalance , NodePort 类型的一种扩展，这使得服务可以通过一个专用的负载均衡器来访问，这是由 Kubernetes 中正在运行的云基础设施提供的。负载均衡器将流量重定向到跨所有节点的节点端口。客户端通过负载均衡器的 IP 连接到服务。
Ingress
创建一个 Ingress 资源，这是一个完全不同的机制，通过一个IP地址公开多个服务,就是一个网关入口。

loadbalance 方式的 service 有 external IP，是对外的

ClusterIP

ClusterIP 主要在每个 node 节点使用 iptables ，将发向 ClusterIP 对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应 pod 的地址和端口，进而把数据转发给对应的 pod 的地址和端口。

为了实现图上的功能，主要需要以下几个组件的协同工作：

apiserver：用户通过 kubectl 命令向 apiserver 发送创建 service 的命令， apiserver 接收到请求后将数据存储到 etcd 中 kube-proxy： Kubernetes的每个节点中都有一个叫做 kube-porxy 的进程，这个进程负责感知 service、 pod 的变化，并将变化的信息写入本地的 iptables 规则中iptables：使用 NAT 等技术将 virtualIP 的流量转至 endpoint 中创建 myapp-deploy.yaml 文件

#1. 创建 Service 的 YAML 描述文件
# cat datarc-deployment-test1-svc.yaml
apiVersion: apps/v1
kind: Namespace
metadata:
  name: datarc
  
---

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: datarc
  name: datarc-test-pod
  labels:
    app: datarc
spec:
  replicas: 2
  selector:
    matchLabels:
      app: datarc
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: datarc
    spec:
      containers:
      - image: nginx:1.13
        name: datarc-1
        resources: {}
status: {}

---

apiVersion: v1
kind: Service
metadata:
  namespace: datarc
  name: datarc-test-pod
spec:
  type: ClusterIP
  selector:
    app: datarc
  ports:
  - name: http
    port: 80
    targetport: 8080
 
 
# 创建 Service 资源
kubectl apply -f datarc-deployment-test1-svc.yaml

# 查看 SVC

> kubectl get svc
> kubectl describe svc -n <svcName>

NodePort

在 k8s 上可以给 Service 设置成 NodePort 类型，这样的话可以让 Kubernetes 在其所有节点上开放一个端口给外部访问（所有节点上都使用相同的端口号），并将传入的连接转发给作为 Service 服务对象的 pod。这样我们的 pod 就可以被外部请求访问。

（NodePort的原理在于在 Node上开了一个端口，将向该端口的流量导入到 kube-proxy，然后由 kube-proxy进一步到给对应的 pod）

#1. 创建 Service 的 YAML 描述文件
# cat datarc-deployment-test1-svc.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: datarc
  
---

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: datarc
  name: datarc-test-pod
  labels:
    app: datarc
spec:
  replicas: 2
  selector:
    matchLabels:
      app: datarc
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: datarc
    spec:
      containers:
      - image: nginx:1.13
        name: datarc-1
        resources: {}
status: {}

---

apiVersion: v1
kind: Service
metadata:
  namespace: datarc
  name: datarc-svc
spec:
  type: NodePort
  selector:
    app: datarc
  ports:
  - name: http
    port: 80
    targetPort: 80
 
 
# 创建 Service 资源
kubectl apply -f datarc-deployment-test1-svc.yaml

注：spec.ports.nodePort这个参数是指Node节点对外开放访问的端口号，如果不指定，则Kubernetes会随机选择一个端口号

相关命令：

查看 SVC

kubectl get svc

kubectl describe svc -n

NodePort总结

简单易用，但是服务一旦多起来，NodePort 在每个节点上开启的端口会及其庞大，而且难以维护，所以生产环境不建议这么使用

Ingress

采用 NodePort 方式暴露服务面临问题是，服务一旦多起来，NodePort 在每个节点上开启的端口会及其庞大，而且难以维护；如果采用 LoadBalane，每个服务都得开放一个公网IP，也会很庞大。这时候 Ingress 暴露服务就是一种很合适的方案。可以通过一个 Ingress 暴露多个服务。

在这里插入图片描述

我们可以能否使用一个Nginx直接对内进行转发呢？众所周知的是，Pod与Pod之间是可以互相通信的，而Pod是可以共享宿主机的网络名称空间的，也就是说当在共享网络名称空间时，Pod上所监听的就是Node上的端口。那么这又该如何实现呢？简单的实现就是在每个 Node 上监听 80，然后写好规则，因为 Nginx 外面绑定了宿主机 80 端口（就像 NodePort），本身又在集群内，那么向后直接转发到相应 Service IP 就行了，如下图所示：

在这里插入图片描述

Ingress 简单的理解就是你原来需要改 Nginx 配置，然后配置各种域名对应哪个 Service，现在把这个动作抽象出来，变成一个 Ingress 对象，你可以用 yaml 创建，每次不要去改 Nginx 了，直接改 yaml 然后创建/更新就行了；那么问题来了：”Nginx 怎么才能动态处理配置？”

注：Ingress资源时基于HTTP虚拟主机或URL的转发规则，需要强调的是，这是一条转发规则，没有任何功能，创建了Ingress对象，Ingress Controller会去动态感知和更新Ingress对象的转发规则

Ingress Controller 这东西就是解决 “Nginx 怎么才能动态处理配置” 的程序（可以简单理解成Ngixn程序，实际不一定，实现方案有很多种）；Ingress Controoler 通过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，然后读取他，按照他自己模板生成一段 Nginx 配置，再写到 Nginx Pod 里，最后 reload 一下.

实际上，Ingress相当于一个7层的负载均衡器，是 kubernetes 对反向代理的一个抽象，它的工作原理类似于 Nginx，可以理解成在 Ingress 里建立诸多映射规则

Ingress Controller通过监听这些配置规则并转化成Nginx的反向代理配置 , 然后对外部提供服务。在这里有两个核心概念：

ingress：kubernetes中的一个对象，给管理员提供一个定义请求如何转发到 service 的规则的定义方法
ingress controller：具体实现反向代理及负载均衡的程序，对 ingress 定义的规则进行解析，根据配置的规则来实现请求转发，实现方式有很多，比如 Nginx, Contour, Haproxy

Ingress（以Nginx为例）的工作原理如下：

用户编写Ingress规则，说明哪个域名对应kubernetes集群中的哪个Service
Ingress控制器动态感知Ingress服务规则的变化，然后生成一段对应的Nginx反向代理配置
Ingress控制器会将生成的Nginx配置写入到一个运行着的Nginx服务中，并动态更新
到此为止，其实真正在工作的就是一个Nginx了，内部配置了用户定义的请求转发规则

在这里插入图片描述

Ingress 安装

#1. 安装 Ingress 镜像
mkdir ingress-nginx && cd ingress-nginx && wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.3/deploy/static/provider/baremetal/deploy.yaml

#2. 执行下载好的 yaml
kubectl apply -f ingress-controller-1.1.yaml

#3. 默认在 ingress-nginx 这个命名空间下
kubectl get pods -n ingress-nginx

#4. 查看暴露的 service 端口
kubectl get pods,svc -n ingress-nginx

创建 Service

#1. ingress是代理 service 的，在使用 ingress 前要先有创建 service
kubectl get svc

#2. 以 nginx 的 service 为例
#cat datarc-ingress.yaml

apiVersion: apps/v1
kind: Namespace
metadata:
  name: datarc
  
---

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: datarc
  name: datarc-test-pod
  labels:
    app: datarc
spec:
  replicas: 2
  selector:
    matchLabels:
      app: datarc
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: datarc
    spec:
      containers:
      - image: nginx:1.13
        name: datarc-1
        resources: {}
status: {}

---

apiVersion: v1
kind: Service
metadata:
  namespace: datarc
  name: datarc-svc
spec:
  type: NodePort
  selector:
    app: datarc
  ports:
  - name: http
    port: 80
    targetPort: 80

---

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web1
spec:
  ingressClassName: "nginx"    # 可修改
  rules:
  - host: web.linuxnbg.com    # 可修改
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: datarc        # 可修改
            port: 			   # 可修改
              number: 80       # 可修改
              
#3. service 是此 ingress 绑定的 service
kubectl apply -f ingress1.yaml

Ingress 使用

#1. 创建规则
 kubectl apply -f xxx.yaml 
 
#2. 查看
 kubectl get ingress
 
#3. 测试 
#本地电脑绑定hosts记录对应ingress里面配置的域名 例： web.linuxnbg.com
#例如这可以生成一个示例yaml
kubectl create ingress web1 --rule=host/path=web:80 --dry-run=client -o yaml

apiVersion: extensions/v1beta1		
kind: Ingress		
metadata:			
  name: ingress-myapp   
  namespace: default     
  annotations:          
    kubernetes.io/ingress.class: "nginx"
spec:     
  rules:   
  - host: web.linuxnbg.com   
    http:
      paths:       
      - path:       
        backend:    
          serviceName: datarc
          servicePort: 80

商务专线没有IP（联通），可换楼层，换楼的话，提前询问，是否能换	半年	网络
50M	2800	相对稳
100M	4750（5000）	相对稳

拨号上网
200M	2700	不稳
300M	3000	不稳

专线有固定IP 50M	2万左右	稳

访问

#1. 查看 ingress 
kubectl get ingress

代表含义：images名、代理的service名、代理的域名、节点所在ip、服务走的端口

#2. 整个访问流程：
Service NodePort 访问 Ingress Controller：
域名（web.linuxnbg.com:32613） -> 公网负载均衡器(80) -> service nodeport（80:32613/TCP,443:31743/TCP）-> iptables/ipvs -> ingress controller Pod（nginx，基于域名分流） -> 分布在各个节点上的pod

ingress 切换宿主机 ip

#1. 在ingress的yaml中搜索containers
在 containers 上新加以下字段，与 containers同级
hostNetwork: True

#2. 重建
kubectl apply -f ingress-controller-1.1.yaml

#3. 访问
此时访问地址变成这样
hostNetwork访问Ingress Controller：
域名（web.linuxnbg.com:80） -> 公网负载均衡器(80) -> 宿主机80端口是ingress controller监听的 -> ingress controller（nginx，基于域名分流） -> 分布在各个节点上的pod
使用network的好处时他避开了service的代理，直接从宿主机访问，更方便快捷，坏处是只能访问他分配到的ip才能访问，没有service那么灵活

ingress总结
ingress 是一个全局入口（80和443），为集群中所有应用转发
公网负载均衡器在其中的作用：

将k8s节点（内网）暴露到互联网上
是互联网用户统一访问入口，特别是针对 service nodeport
加强k8s网络安全

ingress 有两种部署方式，因为他本质上也是一个 pod

pod创建，用service在对他进行代理（官方默认）。
直接共用宿主机网络，将端口暴露在宿主机。

在这里插入图片描述

#1. 安装 Ingress 镜像

mkdir ingress-nginx && cd ingress-nginx

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.3/deploy/static/provider/baremetal/deploy.yaml

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml &&
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml

ingress有两种部署方式，因为他本质上也是一个pod，所以他有两种暴露方式，第一种。pod创建，用service在对他进行代理。第二种。直接共用宿主机网络，将端口暴露在宿主机
官方yaml默认是由service代理的


# 修改mandatory.yaml文件中的仓库
# 修改quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
# 为quay-mirror.qiniu.com/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
# 创建ingress-nginx
[root@master ingress-controller]# kubectl apply -f ./

# 查看ingress-nginx
[root@master ingress-controller]# kubectl get pod -n ingress-nginx
NAME                                           READY   STATUS    RESTARTS   AGE
pod/nginx-ingress-controller-fbf967dd5-4qpbp   1/1     Running   0          12h

# 查看service
[root@master ingress-controller]# kubectl get svc -n ingress-nginx






#2. 拷贝配置文件
# cat deploy.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: udp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: default-http-backend
  labels:
    app: default-http-backend
  namespace: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: default-http-backend
  template:
    metadata:
      labels:
       app: default-http-backend
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: default-http-backend
        image:  registry.cn-qingdao.aliyuncs.com/kubernetes_xingej/defaultbackend-amd64:1.5      #建议提前在node节点下载镜像；
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
        ports:
        - containerPort: 8080
        resources:
         # 这里调整了cpu和memory的大小，可能不同集群限制的最小值不同，看部署失败的原因就清楚
          limits:
            cpu: 100m
            memory: 100Mi
          requests:
            cpu: 100m
            memory: 100Mi
---
apiVersion: v1
kind: Service
metadata:
  name: default-http-backend
  # namespace: ingress-nginx
  namespace: ingress-nginx
  labels:
    app: default-http-backend
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: default-http-backend
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: nginx-ingress-clusterrole
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
  - apiGroups:
      - "extensions"
      - "networking.k8s.io"
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "extensions"
      - "networking.k8s.io"
    resources:
      - ingresses/status
    verbs:
      - update
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-nginx"
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - get
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: nginx-ingress-role-nisa-binding
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: nginx-ingress-clusterrole-nisa-binding
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress-clusterrole
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      # wait up to five minutes for the drain of connections
      terminationGracePeriodSeconds: 300
      serviceAccountName: nginx-ingress-serviceaccount
      nodeSelector:
        kubernetes.io/os: linux
      containers:
        - name: nginx-ingress-controller
          image: suisrc/ingress-nginx:0.30.0   #建议提前在node节点下载镜像；
          args:
            - /nginx-ingress-controller
            - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
          securityContext:
            allowPrivilegeEscalation: true
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
            # www-data -> 101
            runAsUser: 101
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
            - name: https
              containerPort: 443
              protocol: TCP
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10
          lifecycle:
            preStop:
              exec:
                command:
                  - /wait-shutdown
---
apiVersion: v1
kind: LimitRange
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  limits:
  - min:
      memory: 90Mi
      cpu: 100m
    type: Container
---
apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
      # HTTP
      nodePort: 80
    - name: https
      port: 443
      targetPort: 443
      protocol: TCP
     # HTTPS
      nodePort: 443
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

1
2
3

注：
1.简单的来说，就是每个Node节点通过NodePort类型的Service绑定80端口，转发请求给我们的Ingress-Controller的Pod（类似于Nginx）, Ingress-Controller再根据域名规则转发给我们其他的Service的Pod,Ingress-Controller可以动态感知Ingress对象，读取Ingress对象的规则，生成一段Ngixn的转发规则配置
2.Ingress这段是参考网友博客的，感觉描述的很好就搬过来了，下面有原文地址

总结：

K8S Ingress = 微服务网关，本质：七层反向代理，微服务集中出入口

1
2
3


cd 安装目录