基本情況介紹

一、service

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

type 類型

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

ClusterIP：通過為 Kubernetes 的 Service 分配一個(gè)集群內(nèi)部可訪問的固定虛擬IP（Cluster IP），實(shí)現(xiàn)集群內(nèi)的訪問；
NodePort：將 service 的 port 映射到集群內(nèi)每個(gè)節(jié)點(diǎn)的相同一個(gè)端口，實(shí)現(xiàn)通過 nodeIP:nodePort 從集群外訪問服務(wù)；
LoadBalance：向所使用的公有云申請(qǐng)一個(gè)負(fù)載均衡器(負(fù)載均衡器后端映射到各節(jié)點(diǎn)的 nodePort)，實(shí)現(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 上進(jìn)入容器。

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

IP

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

Cluster IP：虛擬地址，由 kube-proxy 使用 iptables 規(guī)則重新定向到其本地端口，再均衡到后端Pod。當(dāng) kube-proxy 發(fā)現(xiàn)一個(gè)新的 service 后，它會(huì)在本地節(jié)點(diǎn)打開一個(gè)任意端口，創(chuàng)建相應(yīng)的iptables 規(guī)則，重定向服務(wù)的 clusterIP 和 port 到這個(gè)新建的端口，開始接受到達(dá)這個(gè)服務(wù)的連接。
Pod IP：每個(gè) Pod 啟動(dòng)時(shí)，會(huì)自動(dòng)創(chuàng)建一個(gè)鏡像為 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ù)作為一個(gè)應(yīng)用程序內(nèi)部的層次，使的服務(wù)可以從集群外部訪問，指定 service 的spec.type=NodePort，通過 nodeip：nodeport 從集群外訪問服務(wù)。

工作方式

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

MetalLB 基本介紹

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

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

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

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

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

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

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

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

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

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

地址分配（address allocation）

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

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

外部公告（external announcement）

外部公告的主要功能就是要把服務(wù)類型為L(zhǎng)oadBalancer的服務(wù)的IP公布到網(wǎng)絡(luò)中去，確?？蛻舳四軌蛘ＴL問到這個(gè) IP 。MetalLB 對(duì)此的實(shí)現(xiàn)方式主要有三種：ARP/NDP和BGP；其中 ARP/NDP 分別對(duì)應(yīng)IPv4/IPv6 協(xié)議的 Layer2 模式，BGP路由協(xié)議則是對(duì)應(yīng) BGP 模式。

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

工作原理

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

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

安裝

安裝之前的準(zhǔn)備檢查工作

如果您在IPVS模式下使用kube-proxy，則從Kubernetes v1.14.2開始，您必須啟用嚴(yán)格的ARP模式。請(qǐng)注意，如果您將kube-router用作服務(wù)代理，則不需要此設(shè)置，因?yàn)槟J(rèn)情況下它啟用了嚴(yán)格的arp。

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

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

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

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"  # 這個(gè)在安裝時(shí)默認(rèn)選擇了ipvs
ipvs:
  strictARP: true # 修改這個(gè)

更新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    #查看里面需要的鏡像 

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

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

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

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

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

配置

接下來我們要生成一個(gè) Configmap 文件，為 Metallb 設(shè)置網(wǎng)址范圍以及協(xié)議相關(guān)的選擇和配置，這里以一個(gè)簡(jiǎ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 地址范圍需要跟集群實(shí)際情況相對(duì)應(yīng)。(跟集群主機(jī)節(jié)點(diǎn)的私網(wǎng)IP對(duì)應(yīng)，可以理解成同網(wǎng)段尚未使用的IP所在網(wǎng)段范圍)

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

測(cè)試

我們創(chuàng)建一個(gè)svc進(jìn)行測(cè)試

# 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  #指定一個(gè) 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)分配到了一個(gè)地址池中的ip

集群內(nèi)部訪問

集群外部訪問

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

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

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

從DeamonSet 類型修改成 Deployment類型

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

此時(shí)訪問路徑為：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

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

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

calico簡(jiǎn)介：

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

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

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

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

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

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

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