前言：

Kubernetes暴露服務(wù)的方式目前只有三種：LoadBlancer Service、NodePort Service、Ingress;這一片主要聊聊Ingress。

一、Ingress

簡(jiǎn)單說，是一個(gè)代理，可以根據(jù)配置轉(zhuǎn)發(fā)請(qǐng)求到指定的服務(wù)上。

1.1 Ingress概念

通俗來講，ingress和之前提到的Service、Deployment，也是一個(gè)k8s的資源類型，ingress用于實(shí)現(xiàn)用域名的方式訪問k8s內(nèi)部應(yīng)用。

Ingress為Kubernetes集群中的服務(wù)提供了入口，可以提供負(fù)載均衡、SSL終止和基于名稱的虛擬主機(jī)，在生產(chǎn)環(huán)境中常用的Ingress有Treafik、Nginx、HAProxy、Istio等。

1.2 基本概念

在Kubernetesv 1.1版中添加的Ingress用于從集群外部到集群內(nèi)部Service的HTTP和HTTPS路由，流量從Internet到Ingress再到Services最后到Pod上，通常情況下，Ingress部署在所有的Node節(jié)點(diǎn)上。

Ingress可以配置提供服務(wù)外部訪問的URL、負(fù)載均衡、終止SSL，并提供基于域名的虛擬主機(jī)。但I(xiàn)ngress不會(huì)暴露任意端口或協(xié)議。

1.3 為什么需要Ingress資源

由于K8S集群擁有強(qiáng)大的副本控制能力，Pod隨時(shí)可能從一個(gè)節(jié)點(diǎn)上被驅(qū)逐到另一個(gè)節(jié)點(diǎn)上，或者直接銷毀再來一個(gè)新的。

然而伴隨著Pod的銷毀和重生，Pod的IP等信息不斷地在改變，此時(shí)使用K8S提供的Service機(jī)制可以解決這一問題，Service通過標(biāo)簽選定指定的Pod作為后端服務(wù)，并監(jiān)聽這些Pod的變化。

在對(duì)外暴露服務(wù)時(shí)，使用Service的NodePort是一個(gè)方法

問題1-如何管理端口

當(dāng)需要對(duì)外暴露的服務(wù)量比較多的時(shí)候，端口管理的問題變會(huì)暴露出來。

此時(shí)的一個(gè)處理方案是使用一個(gè)代理服務(wù)（例如nginx）根據(jù)請(qǐng)求信息將請(qǐng)求轉(zhuǎn)發(fā)到不同的服務(wù)器上。

問題2-如何管理轉(zhuǎn)發(fā)配置

每當(dāng)有新服務(wù)加入，都需要對(duì)該服務(wù)的配置進(jìn)行修改、升級(jí)，在服務(wù)數(shù)量逐漸變多后，該配置項(xiàng)目會(huì)變得越來越大，手工修改的風(fēng)險(xiǎn)也會(huì)逐漸增高。

那么需要一個(gè)工具來簡(jiǎn)化這一過程，希望可以通過簡(jiǎn)單的配置動(dòng)態(tài)生成代理中復(fù)雜的配置，最好還可以順手重新加載配置文件。

K8S剛好也提供了此類型資源。

1.4 Pod漂移問題

眾所周知 Kubernetes 具有強(qiáng)大的副本控制能力，能保證在任意副本(Pod)掛掉時(shí)自動(dòng)從其他機(jī)器啟動(dòng)一個(gè)新的，還可以動(dòng)態(tài)擴(kuò)容等，總之一句話，這個(gè) Pod 可能在任何時(shí)刻出現(xiàn)在任何節(jié)點(diǎn)上，也可能在任何時(shí)刻死在任何節(jié)點(diǎn)上；那么自然隨著 Pod 的創(chuàng)建和銷毀，Pod IP 肯定會(huì)動(dòng)態(tài)變化；那么如何把這個(gè)動(dòng)態(tài)的 Pod IP 暴露出去？這里借助于 Kubernetes 的 Service 機(jī)制，Service 可以以標(biāo)簽的形式選定一組帶有指定標(biāo)簽的 Pod，并監(jiān)控和自動(dòng)負(fù)載他們的 Pod IP，那么我們向外暴露只暴露 Service IP 就行了；這就是 NodePort 模式：即在每個(gè)節(jié)點(diǎn)上開起一個(gè)端口，然后轉(zhuǎn)發(fā)到內(nèi)部 Pod IP 上，如下圖所示

1.5 端口管理問題

采用 NodePort 方式暴露服務(wù)面臨一個(gè)坑爹的問題是，服務(wù)一旦多起來，NodePort 在每個(gè)節(jié)點(diǎn)上開啟的端口會(huì)及其龐大，而且難以維護(hù)；這時(shí)候引出的思考問題是?“能不能使用 Nginx 啥的只監(jiān)聽一個(gè)端口，比如 80，然后按照域名向后轉(zhuǎn)發(fā)？”?這思路很好，簡(jiǎn)單的實(shí)現(xiàn)就是使用 DaemonSet 在每個(gè) node 上監(jiān)聽 80，然后寫好規(guī)則，因?yàn)?Nginx 外面綁定了宿主機(jī) 80 端口(就像 NodePort)，本身又在集群內(nèi)，那么向后直接轉(zhuǎn)發(fā)到相應(yīng) Service IP 就行了，如下圖所示

1.6 域名分配及動(dòng)態(tài)更新問題?

從上面的思路，采用 Nginx 似乎已經(jīng)解決了問題，但是其實(shí)這里面有一個(gè)很大缺陷：每次有新服務(wù)加入怎么改 Nginx 配置？總不能手動(dòng)改或者來個(gè) Rolling Update 前端 Nginx Pod 吧？這時(shí)候 “偉大而又正直勇敢的” Ingress 登場(chǎng)，如果不算上面的 Nginx，Ingress 只有兩大組件：Ingress Controller 和 Ingress

Ingress 這個(gè)玩意，簡(jiǎn)單的理解就是?你原來要改 Nginx 配置，然后配置各種域名對(duì)應(yīng)哪個(gè) Service，現(xiàn)在把這個(gè)動(dòng)作抽象出來，變成一個(gè) Ingress 對(duì)象，你可以用 yml 創(chuàng)建，每次不要去改 Nginx 了，直接改 yml 然后創(chuàng)建/更新就行了；那么問題來了：”Nginx 咋整？”

Ingress Controller 這東西就是解決 “Nginx 咋整” 的；Ingress Controoler 通過與 Kubernetes API 交互，動(dòng)態(tài)的去感知集群中 Ingress 規(guī)則變化，然后讀取他，按照他自己模板生成一段 Nginx 配置，再寫到 Nginx Pod 里，最后 reload 一下，工作流程如下圖

?當(dāng)然在實(shí)際應(yīng)用中，最新版本 Kubernetes 已經(jīng)將 Nginx 與 Ingress Controller 合并為一個(gè)組件，所以 Nginx 無需單獨(dú)部署，只需要部署 Ingress Controller 即可

1.7 Ingress的工作方式

Ingress 工作原理
（1）ingress-controller通過和 kubernetes APIServer 交互，動(dòng)態(tài)的去感知集群中ingress規(guī)則變化，
（2）然后讀取它，按照自定義的規(guī)則，規(guī)則就是寫明了哪個(gè)域名對(duì)應(yīng)哪個(gè)service，生成一段nginx配置，
（3）再寫到nginx-ingress-controller的pod里，這個(gè)ingress-controller的pod里運(yùn)行著一個(gè)Nginx服務(wù)，控制器會(huì)把生成的 nginx配置寫入 /etc/nginx.conf文件中，
（4）然后reload一下使配置生效。以此達(dá)到域名區(qū)分配置和動(dòng)態(tài)更新的作用。

在使用普通的Service時(shí)，集群中每個(gè)節(jié)點(diǎn)的kube-proxy在監(jiān)聽到Service和Endpoints的變化時(shí)，會(huì)動(dòng)態(tài)的修改相關(guān)的iptables的轉(zhuǎn)發(fā)規(guī)則。 客戶端在訪問時(shí)通過iptables設(shè)置的規(guī)則進(jìn)行路由轉(zhuǎn)發(fā)達(dá)到訪問服務(wù)的目的。

而Ingress則跳過了kube-proxy這一層，通過Ingress Controller中的代理配置進(jìn)行路由轉(zhuǎn)發(fā)達(dá)到訪問目標(biāo)服務(wù)的目的。

?實(shí)際上可以把IngressController看做一個(gè)擁有默認(rèn)處理后端的代理，根據(jù)Ingress資源的配置動(dòng)態(tài)修改代理的配置文件，以實(shí)現(xiàn)按照規(guī)則轉(zhuǎn)發(fā)請(qǐng)求的功能。

1.8 Ingress配置項(xiàng)

type Ingress struct {
    metav1.TypeMeta `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty"`

    // Ingess配置。
    Spec IngressSpec `json:"spec,omitempty"`

    // Ingress資源當(dāng)前狀態(tài)。
    Status IngressStatus `json:"status,omitempty"`
}
type IngressSpec struct {
    // 默認(rèn)的后端服務(wù)，當(dāng)不匹配所有的Ingress規(guī)則的時(shí)候使用。
    // 一般情況默認(rèn)后端都在Ingress控制器中配置，該字段不進(jìn)行聲明配置。
    // 如果沒有主機(jī)或路徑與 Ingress 對(duì)象中的 HTTP 請(qǐng)求匹配，則流量將路由到您的默認(rèn)后端。
    Backend *IngressBackend `json:"backend,omitempty"`

    // TLS配置。目前Ingress只支持443一種TLS端口。
    // 如果列表中有多個(gè)不同的hosts，將會(huì)在ingress controller支持SNI的情況下,
    // 通過使用SNI TLS擴(kuò)展中聲明的主機(jī)名，在同個(gè)端口下使用多路復(fù)用。
    TLS []IngressTLS `json:"tls,omitempty"`

    // Ingress的規(guī)則。未匹配到規(guī)則列表中規(guī)則的請(qǐng)求將會(huì)被轉(zhuǎn)發(fā)到默認(rèn)后端上。
    Rules []IngressRule `json:"rules,omitempty"`
}
type IngressBackend struct {
    // 服務(wù)名。
    ServiceName string `json:"serviceName"`

    // 服務(wù)的端口。
    ServicePort intstr.IntOrString `json:"servicePort"`
}
type IngressRule struct {
    // 域名。
    // 不能使用IP地址，不能使用端口。對(duì)HTTP服務(wù)使用80端口，HTTPS服務(wù)使用443端口。
    Host string `json:"host,omitempty"`

    // 域名下的具體轉(zhuǎn)發(fā)規(guī)則。
    // 未定義的情況下會(huì)將請(qǐng)求轉(zhuǎn)發(fā)至默認(rèn)后端。
    IngressRuleValue `json:",inline,omitempty"`
}
type IngressRuleValue struct {
    HTTP *HTTPIngressRuleValue `json:"http,omitempty"`
}
type HTTPIngressRuleValue struct {
    Paths []HTTPIngressPath `json:"paths"`
}
type HTTPIngressPath struct {
    // 匹配的路徑，必須以/為開頭。
    // 未定義的情況下會(huì)將請(qǐng)求轉(zhuǎn)發(fā)至默認(rèn)后端。
    Path string `json:"path,omitempty"`

    // 處理請(qǐng)求的后端服務(wù)。
    Backend IngressBackend `json:"backend"`
}

二、部署使用Ingress?

2.1 部署 nginx-ingress-controller

1、部署ingress-controller pod及相關(guān)資源

[root@k8s-master opt]# mkdir /opt/ingress
[root@k8s-master opt]# cd ingress/
[root@k8s-master ingress]# wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.25.0/deploy/static/mandatory.yaml
--2022-08-09 17:07:00--  https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.25.0/deploy/static/mandatory.yaml
正在解析主機(jī) raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.111.133, 185.199.110.133, 185.199.108.133, ...
正在連接 raw.githubusercontent.com (raw.githubusercontent.com)|185.199.111.133|:443... 已連接。
已發(fā)出 HTTP 請(qǐng)求，正在等待回應(yīng)... 200 OK
長(zhǎng)度：5976 (5.8K) [text/plain]
正在保存至: “mandatory.yaml”

100%[===================================================================>] 5,976       --.-K/s 用時(shí) 0s      

2022-08-09 17:07:00 (99.1 MB/s) - 已保存 “mandatory.yaml” [5976/5976])

[root@k8s-master ingress]# ll
總用量 8
-rw-r--r--. 1 root root 5976 8月   9 17:07 mandatory.yaml

官方下載地址：

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.25.0/deploy/static/mandatory.yaml

上面的下載地址可能無法下載，可用國內(nèi)的Gitee地址

wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.25.0/deploy/static/mandatory.yaml
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/mandatory.yaml

?#mandatory.yaml文件中包含了很多資源的創(chuàng)建，包括namespace、ConfigMap、role，ServiceAccount等等所有部署ingress-controller需要的資源。

2.2 修改ClusterRole資源配置

vim mandatory.yaml
......
apiVersion: rbac.authorization.k8s.io/v1beta1
#RBAC相關(guān)資源從1.17版本開始改用rbac.authorization.k8s.io/v1，rbac.authorization.k8s.io/v1beta1在1.22版本即將棄用
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:
      - "extensions"
      - "networking.k8s.io"    # （0.25版本）增加 networking.k8s.io Ingress 資源的 api 
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
  - apiGroups:
      - "extensions"
      - "networking.k8s.io"   # （0.25版本）增加 networking.k8s.io/v1 Ingress 資源的 api 
    resources:
      - ingresses/status
    verbs:
      - update

2.3 ingress 暴露服務(wù)的方式

●方式一：Deployment+LoadBalancer 模式的 Service
如果要把ingress部署在公有云，那用這種方式比較合適。用Deployment部署ingress-controller，創(chuàng)建一個(gè) type為 LoadBalancer 的 service 關(guān)聯(lián)這組 pod。大部分公有云，都會(huì)為 LoadBalancer 的 service 自動(dòng)創(chuàng)建一個(gè)負(fù)載均衡器，通常還綁定了公網(wǎng)地址。 只要把域名解析指向該地址，就實(shí)現(xiàn)了集群服務(wù)的對(duì)外暴露

●方式二：DaemonSet+HostNetwork+nodeSelector
用DaemonSet結(jié)合nodeselector來部署ingress-controller到特定的node上，然后使用HostNetwork直接把該pod與宿主機(jī)node的網(wǎng)絡(luò)打通，直接使用宿主機(jī)的80/433端口就能訪問服務(wù)。這時(shí)，ingress-controller所在的node機(jī)器就很類似傳統(tǒng)架構(gòu)的邊緣節(jié)點(diǎn)，比如機(jī)房入口的nginx服務(wù)器。該方式整個(gè)請(qǐng)求鏈路最簡(jiǎn)單，性能相對(duì)NodePort模式更好。缺點(diǎn)是由于直接利用宿主機(jī)節(jié)點(diǎn)的網(wǎng)絡(luò)和端口，一個(gè)node只能部署一個(gè)ingress-controller pod。 比較適合大并發(fā)的生產(chǎn)環(huán)境使用。

●方式三：Deployment+NodePort模式的Service
同樣用deployment模式部署ingress-controller，并創(chuàng)建對(duì)應(yīng)的service，但是type為NodePort。這樣，ingress就會(huì)暴露在集群節(jié)點(diǎn)ip的特定端口上。由于nodeport暴露的端口是隨機(jī)端口，一般會(huì)在前面再搭建一套負(fù)載均衡器來轉(zhuǎn)發(fā)請(qǐng)求。該方式一般用于宿主機(jī)是相對(duì)固定的環(huán)境ip地址不變的場(chǎng)景。
NodePort方式暴露ingress雖然簡(jiǎn)單方便，但是NodePort多了一層NAT，在請(qǐng)求量級(jí)很大時(shí)可能對(duì)性能會(huì)有一定影響。

采用方式二：DaemonSet+HostNetwork+nodeSelector

2.4 指定 nginx-ingress-controller 運(yùn)行在node02 節(jié)點(diǎn)

[root@k8s-master ingress]# kubectl get nodes
NAME         STATUS   ROLES                  AGE    VERSION
k8s-master   Ready    control-plane,master   7d1h   v1.21.3
k8s-node01   Ready    <none>                 7d1h   v1.21.3
k8s-node02   Ready    <none>                 7d1h   v1.21.3
[root@k8s-master ingress]# kubectl label node k8s-node02 ingress=true
node/k8s-node02 labeled
[root@k8s-master ingress]# kubectl get nodes --show-labels
NAME         STATUS   ROLES                  AGE    VERSION   LABELS
k8s-master   Ready    control-plane,master   7d1h   v1.21.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-master,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=,node.kubernetes.io/exclude-from-external-load-balancers=
k8s-node01   Ready    <none>                 7d1h   v1.21.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node01,kubernetes.io/os=linux
k8s-node02   Ready    <none>                 7d1h   v1.21.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,ingress=true,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node02,kubernetes.io/os=linux

2.5 修改Deployment 為 DaemoSet,指定節(jié)點(diǎn)運(yùn)行，并開啟hostNetwork網(wǎng)絡(luò)?

vim mandatory.yaml
...
apiVersion: apps/v1
# 修改 kind
# kind: Deployment
kind: DaemonSet
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
# 刪除Replicas
# replicas: 1
  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:
      # 使用主機(jī)網(wǎng)絡(luò)
      hostNetwork: true
      # 選擇節(jié)點(diǎn)運(yùn)行
      nodeSelector:
        ingress: "true"
      serviceAccountName: nginx-ingress-serviceaccount
......

?2.6 在所有node節(jié)點(diǎn)上傳nginx-ingress-controller 鏡像壓縮包

ingree.contro.tar.gz 到 /opt/ingress 目錄，并解壓和加載鏡像
cd /opt/ingress
tar zxvf ingree.contro.tar.gz
docker load -i ingree.contro.tar
或者使用docker pull拉取鏡像
[root@k8s-master ingress]# docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:0.30.0

2.7??啟動(dòng)nginx-ingress-controller

[root@k8s-master ingress]# kubectl apply -f mandatory.yaml
namespace/ingress-nginx unchanged
configmap/nginx-configuration unchanged
configmap/tcp-services unchanged
configmap/udp-services unchanged
serviceaccount/nginx-ingress-serviceaccount unchanged
Warning: rbac.authorization.k8s.io/v1beta1 ClusterRole is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRole
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole unchanged
Warning: rbac.authorization.k8s.io/v1beta1 Role is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 Role
role.rbac.authorization.k8s.io/nginx-ingress-role unchanged
Warning: rbac.authorization.k8s.io/v1beta1 RoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 RoleBinding
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding unchanged
Warning: rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRoleBinding
clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding unchanged
daemonset.apps/nginx-ingress-controller unchanged
[root@k8s-master ingress]# kubectl get pod -n ingress-nginx -o wide
//nginx-ingress-controller 已經(jīng)運(yùn)行 node02 節(jié)點(diǎn)
NAME                             READY   STATUS    RESTARTS   AGE   IP               NODE         NOMINATED NODE   READINESS GATES
nginx-ingress-controller-nhsxt   1/1     Running   0          50m   192.168.161.18   k8s-node02   <none>           <none>
[root@k8s-master ingress]# kubectl get cm,daemonset -n ingress-nginx -o wide
NAME                                        DATA   AGE
configmap/ingress-controller-leader-nginx   0      45m
configmap/kube-root-ca.crt                  1      67m
configmap/nginx-configuration               0      67m
configmap/tcp-services                      0      67m
configmap/udp-services                      0      67m

NAME                                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE   CONTAINERS                 IMAGES                                                                  SELECTOR
daemonset.apps/nginx-ingress-controller   1         1         1       1            1           ingress=true    67m   nginx-ingress-controller   quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.25.0   app.kubernetes.io/name=ingress-nginx,app.kubernetes.io/part-of=ingress-nginx

?

?到 node02 節(jié)點(diǎn)查看

[root@k8s-node02 ingress]# netstat -lntp | grep nginx
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      117191/nginx: maste 
tcp        0      0 0.0.0.0:8181            0.0.0.0:*               LISTEN      117191/nginx: maste 
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      117191/nginx: maste 
tcp6       0      0 :::10254                :::*                    LISTEN      117165/nginx-ingres 
tcp6       0      0 :::80                   :::*                    LISTEN      117191/nginx: maste 
tcp6       0      0 :::8181                 :::*                    LISTEN      117191/nginx: maste 
tcp6       0      0 :::443                  :::*                    LISTEN      117191/nginx: maste 

由于配置了 hostnetwork，nginx 已經(jīng)在 node 主機(jī)本地監(jiān)聽 80/443/8181 端口。其中 8181 是 nginx-controller 默認(rèn)配置的一個(gè) default backend（Ingress 資源沒有匹配的 rule 對(duì)象時(shí)，流量就會(huì)被導(dǎo)向這個(gè) default backend）。
這樣，只要訪問 node 主機(jī)有公網(wǎng) IP，就可以直接映射域名來對(duì)外網(wǎng)暴露服務(wù)了。如果要 nginx 高可用的話，可以在多個(gè) node上部署，并在前面再搭建一套 LVS+keepalived 做負(fù)載均衡

?2.8 創(chuàng)建ingress規(guī)則

創(chuàng)建一個(gè)deploy和svc

[root@k8s-master ingress]# vim service-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
spec:
  replicas: 2
  seleector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-app-svc
spec:
  type: ClusterIP
  ports:
  - protocol: TCP
    prot: 80
    targetPort:
  selector:
    app: nginx

?創(chuàng)建ingress

#方法一：（extensions/v1beta1 Ingress 在1.22版本即將棄用）
vim ingress-app.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-app-ingress
spec:
  rules:
  - host: www.liang.com
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-app-svc
          servicePort: 80

#方法二：
vim ingress-app.yaml	  
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-app-ingress
spec:
  rules:
  - host: www.liang.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-app-svc
            port:
              number: 80

?

[root@k8s-master ingress]# kubectl apply -f service-nginx.yaml
deployment.apps/nginx-app unchanged
service/nginx-app-svc created
[root@k8s-master ingress]# kubectl apply -f ingress-app.yaml 
ingress.networking.k8s.io/nginx-app-ingress created
[root@k8s-master ingress]# kubectl get pods
NAME                                      READY   STATUS              RESTARTS   AGE
nginx-app-845d4d9dff-4m44r                0/1     Running             0          15m
nginx-app-845d4d9dff-cvxrz                0/1     Running             0          15m
[root@k8s-master ingress]# kubectl get ingress
NAME                CLASS    HOSTS           ADDRESS   PORTS   AGE
nginx-app-ingress   <none>   www.liang.com             80      15m

?2.9 測(cè)試訪問

本地host添加域名解析

[root@k8s-master ingress]# vim /etc/hosts

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.161.16 k8s-master
192.168.161.17 k8s-node01
192.168.161.18 k8s-node02
192.168.161.18 www.liang.com
[root@k8s-master ingress]# curl www.liang.com

2.10 查看 nginx-ingress-controller?

[root@k8s-master ingress]# kubectl get pod -n ingress-nginx -o wide
NAME                             READY   STATUS    RESTARTS   AGE    IP               NODE         NOMINATED NODE   READINESS GATES
nginx-ingress-controller-nhsxt   1/1     Running   0          123m   192.168.161.18   k8s-node02   <none>           <none>
[root@k8s-master ingress]# kubectl exec -it nginx-ingress-controller-nhsxt -n ingress-nginx /bin/bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
www-data@k8s-node02:/etc/nginx$ more /etc/nginx/nginx.conf
可以看到從 start server www.liang.com 到 end server www.liang.com 之間包含了此域名用于反向代理的配置

總結(jié)
ingress是k8s集群的請(qǐng)求入口，可以理解為對(duì)多個(gè)service的再次抽象
通常說的ingress一般包括ingress資源對(duì)象及ingress-controller兩部分組成
ingress-controller有多種實(shí)現(xiàn)，社區(qū)原生的是ingress-nginx，根據(jù)具體需求選擇
ingress自身的暴露有多種方式，需要根據(jù)基礎(chǔ)環(huán)境及業(yè)務(wù)類型選擇合適的方式文章來源地址http://www.zghlxwxcb.cn/news/detail-798112.html

到了這里，關(guān)于K8S中的ingress的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！