又粗又硬整进去好爽视频,亚洲色图网址,校花被强迫np肉高h

基本情況介紹

一、service

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

type 類型

根據創建 Service 的 type 類型不同，主要分為幾下幾種：

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

Port

Service 中主要涉及三種 Port：

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

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

使用 Service 服務會涉及到幾種 IP：

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

工作方式

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

MetalLB 基本介紹

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

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

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

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

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

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

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

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

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

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

地址分配（address allocation）

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

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

外部公告（external announcement）

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

外部公告主要就是由作為daemonset部署的speaker來實現，它負責在網絡中發布 ARP/NDP 報文或者是和 BGP 路由器建立連接并發布 BGP 報文。

工作原理

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

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

安裝

安裝之前的準備檢查工作

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

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

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

并修改如下圖內容

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

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

配置

接下來我們要生成一個 Configmap 文件，為 Metallb 設置網址范圍以及協議相關的選擇和配置，這里以一個簡單的二層配置為例：

# 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 地址范圍需要跟集群實際情況相對應。(跟集群主機節點的私網IP對應，可以理解成同網段尚未使用的IP所在網段范圍)

注意: 新版本使用的配置文件內容有變化，網址：https://metallb.universe.tf/configuration/_advanced_l2_configuration/

測試

我們創建一個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已經分配到了一個地址池中的ip

集群內部訪問

集群外部訪問

metallb跟ingress結合起來使用

對于ingress的yaml文件，可以復制過來進行修改，需要修改網絡模式

去除之前做的節點綁定，不監聽主機的端口

從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網絡插件

calico簡介：

flannel實現的是網絡通信，calico的特性是在pod之間的隔離。
通過BGP路由，但大規模端點的拓撲計算和收斂往往需要一定的時間和計算資源。純三層的轉發，中間沒有任何的NAT和overlay，轉發效率最好。
Calico 僅依賴三層路由可達。Calico 較少的依賴性使它能適配所有 VM、Container、白盒或者混合環境場景。

calico網絡架構

Felix：監聽ECTD中心的存儲獲取事件，用戶創建pod后，Felix負責將其網卡、IP、MAC都設置好，然后在內核的路由表里面寫一條，注明這個IP應該到這張網卡。同樣如果用戶制定了隔離策略，Felix同樣會將該策略創建到ACL中，以實現隔離。

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

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

BGP工作模式：適用于互相訪問的pod在同一個網段，適用于大型網絡。

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

阅读全文

聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容侵權或者其他違規問題，請聯系本站處理。舉報投訴