基本情況介紹

一、service

Kubernetes中一個應(yīng)用服務(wù)會有一個或多個實例，每個實例（Pod）的IP地址由網(wǎng)絡(luò)插件動態(tài)隨機分配（Pod重啟后IP地址會改變）。為屏蔽這些后端實例的動態(tài)變化和對多實例的負載均衡，引入了 Service這個資源對象。

type 類型

根據(jù)創(chuàng)建 Service 的 type 類型不同，主要分為幾下幾種：

ClusterIP：通過為 Kubernetes 的 Service 分配一個集群內(nèi)部可訪問的固定虛擬IP（Cluster IP），實現(xiàn)集群內(nèi)的訪問；
NodePort：將 service 的 port 映射到集群內(nèi)每個節(jié)點的相同一個端口，實現(xiàn)通過 nodeIP:nodePort 從集群外訪問服務(wù)；
LoadBalance：向所使用的公有云申請一個負載均衡器(負載均衡器后端映射到各節(jié)點的 nodePort)，實現(xiàn)從集群外通過 LB 訪問服務(wù)；

Port

Service 中主要涉及三種 Port：

port 表示 service 暴露在 clusterIP 上的端口，clusterIP:Port 是提供給集群內(nèi)部訪問 kubernetes 服務(wù)的入口；
NodePort：提供給從集群外部訪問 kubernetes 服務(wù)的入口；
TargetPort：容器port，targetPort 是 pod 上的端口，從 port 和 nodePort 上到來的數(shù)據(jù)最終經(jīng)過 kube-proxy 流入到后端 pod 的 targetPort 上進入容器。

port 和 nodePort 都是 service 的端口，前者暴露給從集群內(nèi)訪問服務(wù)，后者暴露給從集群外訪問服務(wù)。從這兩個端口到來的數(shù)據(jù)都需要經(jīng)過反向代理 kube-proxy 流入后端具體 pod 的 targetPort，從而進入到 pod 上的容器內(nèi)。

IP

使用 Service 服務(wù)會涉及到幾種 IP：

Cluster IP：虛擬地址，由 kube-proxy 使用 iptables 規(guī)則重新定向到其本地端口，再均衡到后端Pod。當 kube-proxy 發(fā)現(xiàn)一個新的 service 后，它會在本地節(jié)點打開一個任意端口，創(chuàng)建相應(yīng)的iptables 規(guī)則，重定向服務(wù)的 clusterIP 和 port 到這個新建的端口，開始接受到達這個服務(wù)的連接。
Pod IP：每個 Pod 啟動時，會自動創(chuàng)建一個鏡像為 gcr.io/google_containers/pause 的容器，Pod內(nèi)部其他容器的網(wǎng)絡(luò)模式使用container模式，指定為 pause 容器的ID（network_mode: “container:pause 容器ID”），使得 Pod 內(nèi)所有容器共享 pause 容器的網(wǎng)絡(luò)，與外部的通信經(jīng)由此容器代理，pause容器的 IP 也可以稱為Pod IP。
Node IP：將服務(wù)作為一個應(yīng)用程序內(nèi)部的層次，使的服務(wù)可以從集群外部訪問，指定 service 的spec.type=NodePort，通過 nodeip：nodeport 從集群外訪問服務(wù)。

工作方式

定義服務(wù)的時候通過 selector 指定服務(wù)對應(yīng)的 pods，根據(jù) pods 的地址創(chuàng)建出 endpoints 作為服務(wù)后端；Endpoints Controller 會 watch Service 以及 pod 的變化，維護對應(yīng)的 Endpoint 信息。kube-proxy根據(jù) Service 和 Endpoint 來維護本地的路由規(guī)則。當 Endpoint 發(fā)生變化，即 Service 以及關(guān)聯(lián)的pod發(fā)生變化，kube-proxy 都會在每個節(jié)點上更新 iptables，實現(xiàn)一層負載均衡。

MetalLB 基本介紹

官方文檔地址：https://metallb.universe.tf/

該項目發(fā)布于 2017 年底，當前處于 Beta 階段。

MetalLB完全支持的網(wǎng)絡(luò)插件Canal、Cilium、Flannel、Kube-ovn等。如果kube-proxy運行在IPVS模式先，需要設(shè)置strictARP: true（后面會詳細闡述）

Kubernetes不提供網(wǎng)絡(luò)負載均衡器的實現(xiàn)（LoadBalancer類型的服務(wù)）用于裸機集群。Kubernetes附帶的Network LB的實現(xiàn)都是調(diào)用各種IaaS平臺（GCP，AWS，Azure等）的粘合代碼。如果您未在受支持的IaaS平臺（GCP，AWS，Azure等）上運行，則LoadBalancers在創(chuàng)建時將無限期保持“待處理”狀態(tài)。

裸機集群運營商只剩下兩個較小的工具，即“ NodePort”和“ externalIPs”服務(wù)，可將用戶流量引入其集群。這兩個選項在生產(chǎn)用途上都有很大的缺點，這使裸金屬集群成為Kubernetes生態(tài)系統(tǒng)中的二等公民。

MetalLB旨在通過提供與標準網(wǎng)絡(luò)設(shè)備集成的Network LB實現(xiàn)來解決這種不平衡問題，從而使裸機群集上的外部服務(wù)也盡可能“正常運行”。

簡單來說：在裸機集群上(不是公有云廠商的主機，比如阿里云，騰訊云)部署k8s后，外部網(wǎng)絡(luò)訪問集群里的服務(wù)，通過ingress-nginx的形式，但是這個ingress-nginx的服務(wù)service端口類型對外暴露只能使用“ NodePort”和“ externalIPs”服務(wù)，不能使用LoadBalancer的，使用MetalLB則可以解決這個問題，使ingress-nginx的service端口類型對外暴露使用LoadBalancer的形式(不用使用云廠商提供的負載均衡器)

MetalLB是 Kubernetes 集群中關(guān)于LoadBalancer的一個具體實現(xiàn)，主要用于暴露k8s集群的服務(wù)到集群外部訪問。由兩個共同提供此服務(wù)的工作負載（workload）：地址分配和外部公告；對應(yīng)的就是在 k8s中部署的 controller 和 speaker。

Metallb 會在 Kubernetes 內(nèi)運行，監(jiān)控服務(wù)對象的變化，一旦察覺有新的 LoadBalancer 服務(wù)運行，并且沒有可申請的負載均衡器之后，就會完成兩部分的工作：

1.地址分配，用戶需要在配置中提供一個地址池，Metallb 將會在其中選取地址分配給服務(wù)。
2.地址廣播，根據(jù)不同配置，Metallb 會以二層（ARP/NDP）或者 BGP 的方式進行地址的廣播。

地址分配（address allocation）

需要給 MetalLB 分配一段 IP，接著它會根據(jù) service 中的相關(guān)配置來給LoadBalancer的服務(wù)分配IP，LoadBalancer的IP可以手動指定，也可以讓MetalLB自動分配；同時還可以在 MetalLB 的configmap中配置多個 IP 段，并且單獨設(shè)置每個 IP 段是否開啟自動分配。

地址分配（address allocation）主要就是由作為 deployment 部署的 controller 來實現(xiàn)，它負責監(jiān)聽集群中的 service 狀態(tài)并且分配 IP。

外部公告（external announcement）

外部公告的主要功能就是要把服務(wù)類型為LoadBalancer的服務(wù)的IP公布到網(wǎng)絡(luò)中去，確保客戶端能夠正常訪問到這個 IP 。MetalLB 對此的實現(xiàn)方式主要有三種：ARP/NDP和BGP；其中 ARP/NDP 分別對應(yīng)IPv4/IPv6 協(xié)議的 Layer2 模式，BGP路由協(xié)議則是對應(yīng) BGP 模式。

外部公告主要就是由作為daemonset部署的speaker來實現(xiàn)，它負責在網(wǎng)絡(luò)中發(fā)布 ARP/NDP 報文或者是和 BGP 路由器建立連接并發(fā)布 BGP 報文。

工作原理

Metallb 包含兩個組件，Controller 和 Speaker，Controller 為 Deployment 部署方式，而 Speaker 則采用 Daemonset 方式部署到集群內(nèi)部各個Node節(jié)點。

具體的工作原理如下圖所示，Controller 負責監(jiān)聽 Service 變化，當 Service 配置為 LoadBalancer 模式時，從 IP 池分配給到相應(yīng)的 IP 地址并對該 IP 的生命周期進行管理。Speaker 則會依據(jù)選擇的協(xié)議進行相應(yīng)的廣播或應(yīng)答，實現(xiàn) IP 地址的通信響應(yīng)。當業(yè)務(wù)流量通過 TCP/UDP 協(xié)議到達指定的 Node 時，由Node 上面運行的 Kube-Proxy 組件對流量進行處理，并分發(fā)到對應(yīng)服務(wù)的 Pod 上面。

安裝

安裝之前的準備檢查工作

如果您在IPVS模式下使用kube-proxy，則從Kubernetes v1.14.2開始，您必須啟用嚴格的ARP模式。請注意，如果您將kube-router用作服務(wù)代理，則不需要此設(shè)置，因為默認情況下它啟用了嚴格的arp。

您可以通過在當前集群中編輯kube-proxy配置來實現(xiàn)：

# kubectl edit configmap -n kube-system kube-proxy

并修改如下圖內(nèi)容

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"  # 這個在安裝時默認選擇了ipvs
ipvs:
  strictARP: true # 修改這個

更新kube-proxy pod

# kubectl get pod -n kube-system |grep kube-proxy | awk '{system("kubectl delete pod "$1" -n kube-system")}'

另外一種修改生效方式：

# see what changes would be made, returns nonzero returncode if different
kubectl get configmap kube-proxy -n kube-system -o yaml | 
sed -e "s/strictARP: false/strictARP: true/" | 
kubectl diff -f - -n kube-system

# actually apply the changes, returns nonzero returncode on errors only
kubectl get configmap kube-proxy -n kube-system -o yaml | 
sed -e "s/strictARP: false/strictARP: true/" | 
kubectl apply -f - -n kube-system

安裝

# mkdir metallb && cd cd metallb/
# wget https://github.com/metallb/metallb/blob/main/config/manifests/metallb-native.yaml
# vim metallb-native.yaml    #查看里面需要的鏡像 

提前將鏡像下載好，上傳至私有倉庫 (quay.io是Red Hat運營的鏡像庫，雖然沒有被墻，但下載還是比較慢?？梢詮倪@個里面找到使用鏡像的最新版本，然后再使用自己的github代理拉取，推送到自己的dockerhub倉庫里)
(下載quay.io的鏡像，可以參考這個文章：https://www.cnblogs.com/hahaha111122222/p/17097890.html)

使用私庫里的鏡像，需要修改metallb-native.yaml文件中使用的鏡像名

Metallb 安裝，會生成自己的命名空間以及 RBAC 配置。

# kubectl apply -f metallb-native.yaml
# kubectl -n metallb-system get all

創(chuàng)建密鑰，否則會出現(xiàn)報錯 ===》 這一步?jīng)]看懂要干啥，可以暫不操作的
# kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"
# kubectl -n metallb-system get secrets

配置

接下來我們要生成一個 Configmap 文件，為 Metallb 設(shè)置網(wǎng)址范圍以及協(xié)議相關(guān)的選擇和配置，這里以一個簡單的二層配置為例：

# vim config.yml
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 172.25.1.100-172.25.1.200

# kubectl apply -f config.yml

注意：這里的 IP 地址范圍需要跟集群實際情況相對應(yīng)。(跟集群主機節(jié)點的私網(wǎng)IP對應(yīng)，可以理解成同網(wǎng)段尚未使用的IP所在網(wǎng)段范圍)

注意: 新版本使用的配置文件內(nèi)容有變化，網(wǎng)址：https://metallb.universe.tf/configuration/_advanced_l2_configuration/

測試

我們創(chuàng)建一個svc進行測試

# vim  nginx.yaml 
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  #externalIPs:
  #- 172.25.2.100
  #clusterIP: None
  #type: NodePort
  type: LoadBalancer  #指定一個 LoadBalancer 類型的 Service
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: myapp:v1

可以看到我們部署的nginx-svc已經(jīng)分配到了一個地址池中的ip

集群內(nèi)部訪問

集群外部訪問

metallb跟ingress結(jié)合起來使用

對于ingress的yaml文件，可以復制過來進行修改，需要修改網(wǎng)絡(luò)模式

去除之前做的節(jié)點綁定，不監(jiān)聽主機的端口

從DeamonSet 類型修改成 Deployment類型

生效并查看
# kubectl apply -f deploy.yaml
# kubectl -n ingress-nginx get all

此時訪問路徑為：user -> vip(metallb) -> ingress-nginx -> svc -> pod

示例

# cat nginx-svc.yml 
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: myapp:v1

# cat ingress-demo.yml 
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: nginx-test
spec:
 # tls:
 #   - hosts:
 #     - www1.westos.org
 #     secretName: tls-secret
  rules:
    - host: www1.westos.org
      http:
        paths:
        - path: /
          backend:
            serviceName: nginx-svc
            servicePort: 80

# kubectl apply -f nginx-svc.yml
# kubectl apply -f  ingress-demo.yml 
# kubectl get ingress
# kubectl describe ingress nginx-test

# kubectl get svc nginx-svc

這里需要給這個ip做好地址解析，然后在外部訪問域名查看效果。

calico網(wǎng)絡(luò)插件

calico簡介：

flannel實現(xiàn)的是網(wǎng)絡(luò)通信，calico的特性是在pod之間的隔離。
通過BGP路由，但大規(guī)模端點的拓撲計算和收斂往往需要一定的時間和計算資源。純?nèi)龑拥霓D(zhuǎn)發(fā)，中間沒有任何的NAT和overlay，轉(zhuǎn)發(fā)效率最好。
Calico 僅依賴三層路由可達。Calico 較少的依賴性使它能適配所有 VM、Container、白盒或者混合環(huán)境場景。

calico網(wǎng)絡(luò)架構(gòu)

Felix：監(jiān)聽ECTD中心的存儲獲取事件，用戶創(chuàng)建pod后，F(xiàn)elix負責將其網(wǎng)卡、IP、MAC都設(shè)置好，然后在內(nèi)核的路由表里面寫一條，注明這個IP應(yīng)該到這張網(wǎng)卡。同樣如果用戶制定了隔離策略，F(xiàn)elix同樣會將該策略創(chuàng)建到ACL中，以實現(xiàn)隔離。

BIRD：一個標準的路由程序，它會從內(nèi)核里面獲取哪一些IP的路由發(fā)生了變化，然后通過標準BGP的路由協(xié)議擴散到整個其他的宿主機上，讓外界都知道這個IP在這里，路由的時候到這里來。

IPIP工作模式：適用于互相訪問的pod不在同一個網(wǎng)段中，跨網(wǎng)段訪問的場景。

BGP工作模式：適用于互相訪問的pod在同一個網(wǎng)段，適用于大型網(wǎng)絡(luò)。

鏈接：https://www.cnblogs.com/hahaha111122222/p/17222696.html