matchLabels

ingress

Ingress 是反向代理規則，用來規定 HTTP/S 請求應該被轉發到哪個 Service 上，比如根據請求中不同的 Host 和 url 路徑讓請求落到不同的 Service 上。

Ingress Controller 就是一個反向代理程序，它負責解析 Ingress 的反向代理規則，如果 Ingress 有增刪改的變動，所有的 Ingress Controller 都會及時更新自己相應的轉發規則，當 Ingress Controller 收到請求后就會根據這些規則將請求轉發到對應的 Service。

Kubernetes 并沒有自帶 Ingress Controller，它只是一種標準，具體實現有多種，需要自己單獨安裝，常用的是 Nginx Ingress Controller 和 Traefik Ingress Controller。

一個集群中可以有多個 Ingress Controller， 在Ingress 中可以指定使用哪一個 Ingress Controller。

 

Ingress Controller 是部署在集群中的，怎么讓 Ingress Controller 本身能夠被外面訪問到呢？

1、Ingress Controller 用 Deployment 方式部署

給它添加一個 Service，類型為 LoadBalancer，這樣會自動生成一個 IP 地址，通過這個 IP 就能訪問到了，并且一般這個 IP 是高可用的（前提是集群支持 LoadBalancer，通常云服務提供商才支持，自建集群一般沒有）；

2、使用 hostPort；

• 1、Ingress Controller 用 DaemonSet 方式部署，使用集群內部的某個或某些節點作為邊緣節點，給 node 添加 label 來標識，使用 nodeSelector 綁定到邊緣節點，保證每個邊緣節點啟動一個 Ingress Controller 實例，用 hostPort 直接在這些邊緣節點宿主機暴露端口，然后我們可以訪問邊緣節點中 Ingress Controller 暴露的端口，這樣外部就可以訪問到 Ingress Controller 了；

• 2、使用非親緣性策略，使需要部署 Ingress Controller 的節點，每個節點都有一個 Ingress Controller 部署，然后用 hostPort 直接在這些邊緣節點宿主機暴露端口，我們就能通過這些節點的 IP 和 hostPort來訪問 Ingress Controller 了。

不過使用 hostPort 這種方式，我們還需要再上面部署一層負載均衡。

什么是 hostPort

這是一種直接定義 Pod 網絡的方式。

hostPort 是直接將容器的端口與所調度的節點上的端口路由，這樣用戶就可以通過宿主機的 IP 加上來訪問 Pod 了，比如：

 k8s 中的部署過程

首先創建namespace

1、創建命名空間

$ kubectl create namespace study-k8s

2、使用 deployment 部署 pod

apiVersion  版本 v1是版本號

kind    此處創建的是Pod，根據實際情況，此處資源類型可以是Deployment、Job、Ingress、Service等。

metadata    包含Pod的一些meta信息，比如名稱、namespace、標簽等信息。

creationTimestamp   當前對象創建日期的時間戳

labels  標識當前對象的標簽，鍵值數據，常被用作挑選條件

app   名稱

name  容器名稱

namespace  命名空間名稱

spec   資源的具體規格

replicas  Pod 的副本數量

selector  用于選擇管理的 Pod

matchLabels   matchLabels通常與selector字段一起使用，出現在Deployment、Service、DaemonSet等資源的定義中。它的作用是指定哪些標簽（Labels）應該被用來選擇和關聯Pods

strategy   strategy字段用于定義Deployment的更新策略，主要包含兩種策略：RollingUpdate和Recreate  默認RollingUpdate

containers    定義 Pod 中的容器列表

image   使用的容器鏡像

resources  字段用于指定Pod或容器可以使用的計算資源量，包括CPU和內存等

type    Service 的類型（如 ClusterIP、NodePort、LoadBalancer）

selector    用于選擇與 Service 關聯的 Pod

ports   定義服務的端口映射

protocol    使用的協議

port    Service 的端口

targetPort   Pod 的端口

?運行

kubectl apply -f go-web.yaml  -n study-k8s

查看運行狀態

kubectl get pods  -n study-k8s

kubectl describe deployment nginx-deploy  -n  study-k8s

3、為服務創建 service

 

protocol    使用的協議

port    Service 的端口

targetPort   Pod 的端口

創建

kubectl apply -f go-web-svc.yaml -n study-k8s

 4、配置 ingress 的轉發策略

service 已經創建成功了，接下來我們使用 ingress

 部署 ingress

 通過K8S創建過程大概理解為：

1.創建namespace

2.創建Deployment，定義pod、業務、pod數量、更新方式

3.創建service 為pod 提供外網訪問的方式，TCP形式  port：service端口  targetPort: pod端口

4.創建Ingress  利用HTTP/HTTPS 定義轉發到哪個service上 根據host  和path 定義哪個service

注意：不管是Deployment  service  Ingress  都是先后順序的  里面關聯了先后順序的name名稱

總結

1、Pod 是 k8s 中集群部署應用和服務的最小單元；

2、RC 是 k8s 集群中最早的保證 Pod 高可用的 API 對象。它的作用就是保證集群中有指定數目的 pod 運行；

3、RS 是新一代 RC，提供同樣的高可用能力，是目前主要使用的對象；

4、Deployment 提供了一種對 Pod 和 ReplicaSet 的管理方式，RS 的使用都是結合 Deployment 來完成的。

5、一般使用 Deployment 來滾動升級一個服務，滾動升級一個服務，實際是創建一個新的 RS，然后逐漸將新 RS 中副本數增加到理想狀態，將舊 RS 中的副本數減小到 0 的復合操作；這樣一個復合操作用一個 RS 是不太好描述的，所以用一個更通用的 Deployment 來描述。

6、RC、RS 和 Deployment 只是保證了支撐服務的微服務 Pod 的數量。但是沒有解決如何訪問這些服務的問題。一個 Pod 只是一個運行服務的實例，隨時可能在節點上停止，然后再新的節點上用一個新的 IP 啟動一個新的 Pod,因此不能使用確定的 IP 和端口號提供服務。這對于業務來說，就不能根據 Pod 的 IP 作為業務調度。kubernetes 就引入了 Service 的概 念，它為 Pod 提供一個入口，主要通過 Labels 標簽來選擇后端Pod，這時候不論后端 Pod 的 IP 地址如何變更，只要 Pod 的 Labels 標簽沒變，那么 業務通過 service 調度就不會存在問題。

7、Service 是后端真實服務的抽象，一個 Service 可以代表多個相同的后端服務；

8、Ingress 是反向代理規則，用來規定 HTTP/S 請求應該被轉發到哪個 Service 上，比如根據請求中不同的 Host 和 url 路徑讓請求落到不同的 Service 上；