天天看點
傳回

Service和Ingress

Service資源及其實作模型

Service資源基于标簽選擇器将一組Pod定義成一個邏輯組合，并通過自己的IP位址和端口排程代理請求至組内的Pod對象之上，它向用戶端隐藏了真實的、處理使用者請求的Pod資源，使得用戶端的請求看上去就像是由Service直接處理并進行響應的一樣

Service和Ingress

Service對象的IP位址也稱為Cluster IP，它位于為Kubernetes叢集配置指定專用IP位址的範圍之内，并且是一種虛拟IP位址，它在Service對象建立後即保持不變，并且能夠被同一叢集中的Pod資源所通路。Service端口用于接收用戶端請求并将其轉發到其後端的Pod中應用的相應端口之上，是以，這種代理機制也稱為“端口代理”（port proxy）或四層代理，它工作于TCP/IP協定棧的傳輸層。

通過其标簽選擇器比對到的後端Pod資源不止一個時，Service資源能夠以負載均衡的方式進行流量排程，實作了請求流量的分發機制。Service與Pod對象之間的關聯關系通過标簽選擇器以松耦合的方式建立，它可以先于Pod對象建立而不會發生錯誤

Service和Ingress

Service資源會通過API Server持續監視着（watch）标簽選擇器比對到的後端Pod對象，并實時跟蹤各對象的變動，例如，IP位址變動、對象增加或減少等。不過，需要特别說明的是，Service并不直接連結至Pod對象，它們之間還有一個中間層—Endpoints資源對象，它是一個由IP位址和端口組成的清單，這些IP位址和端口則來自于由Service的标簽選擇器比對到的Pod資源。這也是很多場景中會使用“Service的後端端點”（Endpoints）這一術語的原因。預設情況下，建立Service資源對象時，其關聯的Endpoints對象會自動建立。

簡單來講，一個Service對象就是工作節點上的一些iptables或ipvs規則，用于将到達Service對象IP位址的流量排程轉發至相應的Endpoints對象指向的IP位址和端口之上。

工作于每個工作節點的kube-proxy元件通過APIServer持續監控着各Service及與其關聯的Pod對象，并将其建立或變動實時反映至目前工作節點上相應的iptables或ipvs規則上。

Service IP事實上是用于生成iptables或ipvs規則時使用的IP位址，它僅用于實作Kubernetes叢集網絡的内部通信，并且僅能夠将規則中定義的轉發服務的請求作為目标位址予以響應，這也是它被稱為虛拟IP的原因之一。kube-proxy将請求代理的相應端點的方式有三種：userspace（使用者空間）、iptables和ipvs。

1.userspace（使用者空間）

Service和Ingress

2.iptables

Service和Ingress
Service和Ingress
Service和Ingress

3.ipvs

Service和Ingress
Service和Ingress

Service資源的基礎應用

Service資源本身并不提供任何服務，真正處理并響應用戶端請求的是後端的Pod資源。

是以Service資源通常要與控制器資源（最為常用的控制器之一是Deployment）協同使用以完成應用的建立和對外釋出。

建立Service資源

建立Service對象的常用方法有兩種：一是直接使用“kubectl expose”指令，另一個是使用資源配置檔案。

定義Service資源對象時，spec的兩個較為常用的内嵌字段分别為selector和ports，分别用于定義使用的标簽選擇器和要暴露的端口。下面的配置清單是一個Service資源示例：

kind: Service
apiVersion: v1
metadata:
  name: myapp-svc
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
           
~]$ kubectl get svc myapp-svc

~]$ kubectl get endpoints myapp-svc

Service資源myapp-svc通過标簽選擇器關聯至标簽為“app=myapp”的各Pod對象，它會自動建立名為myapp-svc的Endpoints資源對象，并自動配置一個ClusterIP，暴露的端口由port字段進行指定，後端各Pod對象的端口則由targetPort給出，也可以使用同port字段的預設值。

也可以不為Service資源指定.spec.selector屬性值，其關聯的Pod資源可由使用者手動建立Endpoints資源進行定義。

Service對象建立完成後即可作為服務被各用戶端通路，但要真正響應這些請求，還是要依賴于各後端的資源對象。

向Service對象請求服務

Service資源的預設類型為ClusterIP，它僅能接收來自于叢集中的Pod對象中的用戶端程式的通路請求。

Service會話粘性

Service資源還支援Session affinity（粘性會話或會話粘性）機制，它能夠将來自同一個用戶端的請求始終轉發至同一個後端的Pod對象，這意味着它會影響排程算法的流量分發功能，進而降低其負載均衡的效果。是以，當用戶端通路Pod中的應用程式時，如果有基于用戶端身份儲存某些私有資訊，并基于這些私有資訊追蹤使用者的活動等一類的需求時，那麼應該啟用session affinity機制。

Session affinity的效果僅會在一定時間期限内生效，預設值為10800秒，超出此時長之後，用戶端的再次通路會被排程算法重新排程。另外，Service資源的Session affinity機制僅能基于用戶端IP位址識别用戶端身份，它會把經由同一個NAT伺服器進行源位址轉換的所有用戶端識别為同一個用戶端，排程粒度粗糙且效果不佳，是以，實踐中并不推薦使用此種方法實作粘性會話。

Service資源通過.spec.sessionAffinity和.spec.sessionAffinityConfig兩個字段配置粘性會話。spec.sessionAffinity字段用于定義要使用的粘性會話的類型，它僅支援使用“None”和“ClientIP”兩種屬性值。

  • None：不使⽤sessionAffinity，預設值。
  • ClientIP：基于用戶端IP位址識别用戶端身份，把來自同一個源IP位址的請求始終排程至同一個Pod對象。

在啟用粘性會話機制時，.spec.sessionAffinityConfig用于配置其會話保持的時長，它是一個嵌套字段，使用格式如下所示，其可用的時長範圍為“1～86400”，預設為10800秒：

sessionAffinity: ClientIP
sessionAffinityConfig:
  clientIP:
    timeoutSeconds: <integer>

服務發現 （Service Discovery）

服務發現⽅式：環境變量

建立Pod資源時，kubelet會将其所屬名稱空間内的每個活動的Service對象以一系列環境變量的形式注入其中。它支援使用Kubernetes Service環境變量以及與Docker的links相容的變量。

1.Kubernetes Service環境變量

Kubernetes為每個Service資源生成包括以下形式的環境變量在内的一系列環境變量，在同一名稱空間中建立的Pod對象都會自動擁有這些變量。

  • {SVCNAME}_SERVICE_HOST
  • {SVCNAME}_SERVICE_PORT
如果SVCNAME中使用了連接配接線，那麼Kubernetes會在定義為環境變量時将其轉換為下劃線。

2.Docker Link形式的環境變量

Docker使用"--link"選項實作容器連接配接時所設定的環境變量形式,在建立Pod對象時，Kubernetes也會将與此形式相容的一系列環境變量注入Pod對象中。

示例說明：例如，在Service資源myapp-svc建立後建立的Pod對象中檢視可用的環境變量，其中以MYAPP_SVC_SERVICE開頭的表示Kubernetes Service環境變量，名稱中不包含“SERVICE”字元串的環境變量為Docker Link形式的環境變量。

基于環境變量的服務發現其功能簡單、易用，但存在一定的局限，例如，僅有那些與建立的Pod對象在同一名稱空間中且事先存在的Service對象的資訊才會以環境變量的形式注入，那些處于不同命名稱空間，或者是在Pod資源建立之後才建立的Service對象的相關環境變量則不會被添加。幸而，基于DNS的發現機制并不存在此類限制。

ClusterDNS和服務發現

Kubernetes系統之上用于名稱解析和服務發現的ClusterDNS是叢集的核心附件之一，叢集中建立的每個Service對象，都會由其自動生成相關的資源記錄。預設情況下，叢集内各Pod資源會自動配置其作為名稱解析伺服器，并在其DNS搜尋清單中包含它所屬名稱空間的域名字尾。

1.擁有ClusterIP的Service資源，需要具有以下類型的資源記錄。

  • A記錄：

    <service>.<ns>.svc.<zone>. <ttl> IN A <cluster-ip>
  • SRV記錄：

    _<port>._<proto>.<service>.<ns>.svc.<zone>. <ttl> IN SRV <weight> <priority> <port-number> <service>.<ns>.svc.<zone>
  • PTR記錄：

    <d>.<c>.<b>.<a>.in-addr.arpa. <ttl> IN PTR <service>.<ns>.svc.<zone>

2.Headless類型的Service資源，需要具有以下類型的資源記錄。

  • <service>.<ns>.svc.<zone>. <ttl> IN A <endpoint-ip>

  • _<port>._<proto>.<service>.<ns>.svc.<zone>. <ttl> IN SRV <weight> <priority> <port-number> <hostname>.<service>.<ns>.svc.<zone>

  • <d>.<c>.<b>.<a>.in-addr.arpa. <ttl> IN PTR <hostname>.<service>.<ns>.svc.<zone>

3.ExternalName類型的Service資源，需要具有CNAME類型的資源記錄。

  • CNAME記錄：

    <service>.<ns>.svc.<zone>. <ttl> IN CNAME <extname>

服務發現方式：DNS

建立Service資源對象時，ClusterDNS會為它自動建立資源記錄用于名稱解析和服務注冊，于是，Pod資源可直接使用标準的DNS名稱來通路這些Service資源。每個Service對象相關的DNS記錄包含如下兩個。

  • {SVCNAME}.{NAMESPACE}.{CLUSTER_DOMAIN}

  • {SVCNAME}.{NAMESPACE}.svc.{CLUSTER_DOMAIN}

"--cluster-dns"指定了叢集DNS服務的工作位址，"--cluster-domain"定義了叢集使用的本地域名，是以，系統初始化時預設會将“cluster.local.”和主機所在的域作為DNS的本地域使用，這些資訊會在Pod建立時以DNS配置的相關資訊注入它的

/etc/resolv.conf

配置檔案中。

  • {NAMESPACE}.svc.{CLUSTER_DOMAIN}

     ：如 default.svc.cluster.local。

  • svc.{CLUSTER_DOMAIN}

     ：如svc.cluster.local

基于DNS的服務發現不受Service資源所在的名稱空間和建立時間的限制。

服務暴露

Service的IP位址僅在叢集内可達，然而，總會有些服務需要暴露到外部網絡中接受各類用戶端的通路，此時，就需要在叢集的邊緣為其添加一層轉發機制，以實作将外部請求流量接入到叢集的Service資源之上，這種操作也稱為釋出服務到外部網絡中。

Service類型

Kubernetes的Service共有四種類型：ClusterIP、NodePort、LoadBalancer和ExternalName。

  • ClusterIP：通過叢集内部IP位址暴露服務，此位址僅在叢集内部可達，無法被叢集外部的用戶端通路，此為預設的Service類型。
  • NodePort：這種類型建立在ClusterIP類型之上，其在每個節點的IP位址的某靜态端口（NodePort）暴露服務，是以，它依然會為Service配置設定叢集IP位址，并将此作為NodePort的路由目标。簡單來說，NodePort類型就是在工作節點的IP位址上選擇一個端口用于将叢集外部的使用者請求轉發至目标Service的ClusterIP和Port，是以，這種類型的Service既可如ClusterIP一樣受到叢集内部用戶端Pod的通路，也會受到叢集外部用戶端通過套接字

    <NodeIP>: <NodePort>

     進⾏的請求。
Service和Ingress
  • LoadBalancer：這種類型建構在NodePort類型之上，其通過cloud provider提供的負載均衡器将服務暴露到叢集外部，是以LoadBalancer一樣具有NodePort和ClusterIP。簡而言之，一個LoadBalancer類型的Service會指向關聯至Kubernetes叢集外部的、切實存在的某個負載均衡裝置，該裝置通過工作節點之上的NodePort向叢集内部發送請求流量。此類型的優勢在于，它能夠把來自于叢集外部用戶端的請求排程至所有節點（或部分節點）的NodePort之上，而不是依賴于用戶端自行決定連接配接至哪個節點，進而避免了因用戶端指定的節點故障而導緻的服務不可用。
Service和Ingress
  • ExternalName：其通過将Service映射至由externalName字段的内容指定的主機名來暴露服務，此主機名需要被DNS服務解析至CNAME類型的記錄。換言之，此種類型并非定義由Kubernetes叢集提供的服務，而是把叢集外部的某服務以DNS CNAME記錄的形式映射到叢集内，進而讓叢集内的Pod資源能夠通路外部的Service的一種實作方式。是以，這種類型的Service沒有ClusterIP和NodePort，也沒有标簽選擇器用于選擇Pod資源，是以也不會有Endpoints存在。
Service和Ingress

NodePort類型的Service資源

NodePort即節點Port，通常在安裝部署Kubernetes叢集系統時會預留一個端口範圍用于NodePort，預設為30000～32767之間的端口。與ClusterIP類型的可省略

.spec.type

屬性所不同的是，定義NodePort類型的Service資源時，需要通過此屬性明确指定其類型名稱。

kind: Service
apiVersion: v1
metadata:
  name: myapp-svc-nodeport
spec:
  type: NodePort
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80  # Cluster IP的端口
    targetPort: 80 # pod中容器暴漏通路端口
    nodePort: 32223 # NodePort

實踐中，并不鼓勵使用者自定義使用的節點端口，除非事先能夠明确知道它不會與某個現存的Service資源産生沖突。無論如何，隻要沒有特别需求，留給系統自動動配置總是較好的選擇。

NodePort類型的Service資源依然會被配置ClusterIP，事實上，它會作為節點從NodePort接⼊流量後轉發的目标位址，目标端口則是與Service資源對應的spec.ports.port屬性中定義的端口

Service和Ingress

是以，對于叢集外部的用戶端來說，它們可經由任何一個節點的節點IP及端口通路NodePort類型的Service資源，而對于叢集内的Pod用戶端來說，依然可以通過ClusterIP對其進行通路。

LoadBalancer類型的Service資源

NodePort類型的Service資源雖然能夠于叢集外部通路得到，但外部用戶端必須得事先得知NodePort和叢集中⾄至少一個節點的IP位址，且標明的節點發生故障時，用戶端還得自行選擇請求通路其他的節點。另外，叢集節點很可能是某IaaS雲環境中使用私有IP位址的VM，或者是IDC中使用私有位址的實體機，這類位址對網際網路用戶端不可達，是以，一般還應該在叢集之外建立一個具有公網IP位址的負載均衡器，由它接入外部用戶端的請求并排程至叢集節點相應的NodePort之上。

需要注意的是，有些環境中可能還需要為Service資源的配置定義添加Annotations。

進一步地，在IaaS環境支援手動指定IP位址時，使用者還可以使用

.spec.loadBalancerIP

指定建立的負載均衡器使用的IP位址，并可使用

.spec.loadBalancerSourceRanges

指定負載均衡器允許的用戶端來源的位址範圍。

ExternalName Service

ExternalName類型的Service資源用于将叢集外部的服務釋出到叢集中以供Pod中的應用程式通路，是以，它不需要使用标簽選擇器關聯任何的Pod對象，但必須要使用spec.externalName屬性定義一個CNAME記錄用于傳回外部真正提供服務的主機的别名，而後通過CNAME記錄值擷取到相關主機的IP位址。

kind: Service
apiVersion: v1
metadata:
  name: external-redis-svc
  namespace: default
spec:
  type: ExternalName
  externalName: redis.ilinux.io
  ports:
  - protocol: TCP
    port: 6379
    targetPort: 6379
    nodePort: 0
  selector: {}

待Service資源external-redis-svc建立完成後，各Pod對象即可通過external-redis-svc或其FQDN格式的名稱external-redis-svc.default.svc.cluster.local通路相應的服務。ClusterDNS會将此名稱以CNAME格式解析為.spec.externalName字段中的名稱，而後通過DNS服務将其解析為相應的主機的IP位址。

由于ExternalName類型的Service資源實作于DNS級别，用戶端将直接接入外部的服務而完全不需要服務代理，是以，它也無須配置ClusterIP，此種類型的服務也稱為Headless Service。

Headless類型的Service資源

Service對象隐藏了各Pod資源，并負責将用戶端的請求流量排程至該組Pod對象之上。不過，偶爾也會存在這樣一類需求：用戶端需要直接通路Service資源後端的所有Pod資源，這時就應該向用戶端暴露每個Pod資源的IP位址，而不再是中間層Service對象的ClusterIP，這種類型的Service資源便稱為Headless Service。

Headless Service對象沒有ClusterIP，至于如何為此類Service資源配置IP位址，則取決于它的标簽選擇器的定義。

  • 具有标簽選擇器：端點控制器（Endpoints Controller）會在API中為其建立Endpoints記錄，并将ClusterDNS服務中的A記錄直接解析到此Service後端的各Pod對象的IP位址上。
  • 沒有标簽選擇器：端點控制器（Endpoints Controller）不會在API中為其建立Endpoints記錄，ClusterDNS的配置分為兩種情形，對ExternalName類型的服務建立CNAME記錄，對其他三種類型來說，為那些與目前Service共享名稱的所有Endpoints對象建立⼀條記錄。

建立Headless Service資源

配置Service資源配置清單時，隻需要将ClusterIP字段的值設定為“None”即可将其定義為Headless類型。下面是一個Headless Service資源配置清單示例，它擁有标簽選擇器：

kind: Service
apiVersion: v1
metadata:
  name: myapp-headless-svc
spec:
  clusterIP: None
  selector:
    app: myapp
  ports:
  - name: httpport
    port: 80
    targetPort: 80

使用資源建立指令“kubectl create”或“kubectl apply”完成資源建立後，使用相關的檢視指令擷取Service資源的相關資訊便可以看出，它沒有ClusterIP，不過，如果标簽選擇器能夠比對到相關的Pod資源，它便擁有Endpoints記錄，這些Endpoints對象會作為DNS資源記錄名稱myapp-headless-svc查詢時的A記錄解析結果

~]$ kubectl describe svc myapp-headless-svc
……
Endpoints: 10.244.1.113:80,10.244.2.13:80,10.244.3.104:80
……

Pod資源發現

根據Headless Service的工作特性可知，它記錄于ClusterDNS的A記錄的相關解析結果是後端Pod資源的IP位址，這就意味着用戶端通過此Service資源的名稱發現的是各Pod資源.

解析結果是Headless Service通過标簽選擇器關聯到的所有Pod資源的IP位址。于是，用戶端向此Service對象發起的請求将直接接入到Pod資源中的應用之上，而不再由Service資源進行代理轉發，它每次接入的Pod資源則是由DNS伺服器接收到查詢請求時以輪詢（roundrobin）的方式傳回的IP位址。

Ingress資源

Kubernetes提供了兩種内建的雲端負載均衡機制（cloud load balancing）用于釋出公共應用，一種是工作于傳輸層的Service資源，它實作的是“TCP負載均衡器”，另一種是Ingress資源，它實作的是“HTTP（S）負載均衡器”。

Service和Ingress

Ingress和Ingress Controller

Ingress是Kubernetes API的标準資源類型之一，它其實是一組基于DNS名稱（host）或URL路徑把請求轉發至指定的Service資源的規則，用于将叢集外部的請求流量轉發至叢集内部完成服務釋出。然而，Ingress資源自身并不能進行流量穿透”，它僅是一組路由規則的集合，這些規則要想真正發揮作用還需要其他功能的輔助，如監聽某套接字，然後根據這些規則的比對機制路由請求流量。這種能夠為Ingress資源監聽套接字并轉發流量的元件稱為Ingress控制器（Ingress Controller）。

Ingress控制器是Kubernetes叢集的一個重要附件，類似于CoreDNS，需要在叢集上單獨部署。

Ingress控制器可以由任何具有反向代理（HTTP/HTTPS）功能的服務程式實作，如Nginx、Envoy、HAProxy、Vulcand和Traefik等。Ingress控制器自身也是運作于叢集中的Pod資源對象，它與被代理的運作為Pod資源的應用運作于同一網絡中。

Service和Ingress

使用Ingress資源進行流量分發時，Ingress控制器可基于某Ingress資源定義的規則将用戶端的請求流量直接轉發至與Service對應的後端Pod資源之上，這種轉發機制會繞過Service資源，進而省去了由kube-proxy實作的端口代理開銷。

建立Ingress資源

Ingress資源是基于HTTP虛拟主機或URL的轉發規則，它在資源配置清單的spec字段中嵌套了rules、backend和tls等字段進行定義。下面的示例中定義了一個Ingress資源，它包含了一個轉發規則，把發往www.k8s.com的請求代理給名為myapp-svc的Service資源：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
  spec:
    rules:
    - host: www.k8s.com
      http:
        paths:
        - backend:
          serviceName: myapp-svc
          servicePort: 80

資源清單中的annotations用于識别其所屬的Ingress控制器的類别，這一點在叢集上部署有多個Ingress控制器時尤為重要。Ingress Spec中的字段是定義Ingress資源的核心組成部分，它主要嵌套如下三個字段。

  • rules
  • backend
  • tls

backend對象的定義由兩個必選的内嵌字段組成：serviceName和servicePort，分别用于指定流量轉發的後端目标Service資源的名稱和端口。

rules對象由一系列配置Ingress資源的host規則組成，這些host規則用于将一個主機上的某個URL路徑映射至相關的後端Service對象，它的定義格式如下：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: jdd-parking-cloud-ui
spec:
  ingressClassName: nginx-ingress-congtoller
  rules:
    - host: test.jdd966.cn
      http:
        paths:
          - backend:
              serviceName: jdd-parking-cloud-ui
              servicePort: 80
            path: /mgr
            pathType: Prefix
  tls:
    - hosts:
        - test.jdd966.cn
      secretName: https-cn

.spec.rules.host

 屬性值目前不支援使用IP位址，也不支援後跟“：PORT”格式的端口号，且此字段值留白表示通配所有的主機名。
tls對象由兩個内嵌字段組成，僅在定義TLS主機的轉發規則時才需要定義此類對象。

hosts：包含于使用的TLS證書之内的主機名稱字元串清單，是以，此處使用的主機名必須比對tlsSecret中的名稱。

secretName：用于引用SSL會話的secret對象名稱，在基于SNI實作多主機路由的場景中，此字段為可選。

Ingress資源類型

基于HTTP暴露的每個Service資源均可釋出于一個獨立的FQDN主機名之上，如“www.ik8s.io”；也可釋出于某主機的URL路徑之上，進而将它們整合到同一個Web站點，如“www.ik8s.io/grafana”。

1.單Service資源型Ingress

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  backend:
    serviceName: my-svc
    servicePort: 80

Ingress控制器會為其配置設定一個IP位址接入請求流量，并将它們轉至示例中的my-svc後端。

2.基于URL路徑進行流量分發

垂直拆分或微服務架構中，每個小的應用都有其專用的Service資源暴露服務，但在對外開放的站點上，它們可能是财經、新聞、電商、無線端或API接口等一類的獨立應用，可通過主域名的URL路徑（path）分别入。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  annotations:
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: www.ilinux.io
    http:
      paths:
      - path: /wap
        backend:
          serviceName: wap
          servicePort: 80
      - path: /api
        backend:
          serviceName: api
          servicePort: 80

3.基于主機名稱的虛拟主機

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
spec:
  rules:
  - host: api.ilinux.io
    http:
      paths:
      - path: 
        backend:
          serviceName: api
          servicePort: 80
  - host: wap.ilinux.io
    http:
      paths:
      - path: 
        backend:
          serviceName: wap
          servicePort: 80

4.TLS類型的Ingress資源

這種類型用于以HTTPS釋出Service資源，基于一個含有私鑰和證書的Secret對象即可配置TLS協定的Ingress資源，目前來說，Ingress資源僅支援單TLS端口，并且還會解除安裝TLS會話。在Ingress資源中引用此Secret即可讓Ingress控制器加載并配置為HTTPS服務。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: no-rules-map
spec:
  tls:
  - secretName: ikubernetesSecret
  backend:
    serviceName: homesite
    servicePort: 80
TLS Secret中包含的證書必須以tls.crt作為其鍵名，私鑰檔案必須以tls.key為鍵名,在Ingress控制器上配置HTTPS主機時，不能直接使用私鑰和證書檔案，而是要使用Secret資源對象來傳遞相關的資料。

部署Ingress控制器（Nginx）

Ingress控制器自身是運作于Pod中的容器應用，一般是Nginx或Envoy一類的具有代理及負載均衡功能的守護程序，它監視着來自于API Server的Ingress對象狀态，并以其規則生成相應的應用程式專有格式的配置檔案并通過重載或重新開機守護程序而使新配置生效。

對于Nginx來說，Ingress規則需要轉換為Nginx的配置資訊。簡單來說，Ingress控制器其實就是托管于Kubernetes系統之上的用于實作在應用層釋出服務的Pod資源，它将跟蹤Ingress資源并實時生成配置規則。

那麼，同樣運作為Pod資源的Ingress控制器程序是如何接⼊外部的請求流量呢？常用的解決方案有如下兩種。

  • 以Deployment控制器管理Ingress控制器的Pod資源，并通過NodePort或LoadBalancer類型的Service對象為其接入叢集外部的請求流量，這就意味着，定義一個Ingress控制器時，必須在其前端定義一個專用的Service資源
Service和Ingress
  • 借助于DaemonSet控制器，将Ingress控制器的Pod資源各自以單一執行個體的方式運作于叢集的所有或部分工作節點之上，并配置這類Pod對象以hostPort或hostNetwork的方式在目前節點接入外部流量。
Service和Ingress
上一篇: 實戰 Kubernetes 中部署 MySQL 叢集
下一篇: MyBatis：mybatis-config.xml配置檔案詳解