成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

Kubernetes 多區域擴展輕松搞定：遠不像你想象的那么難！

企業動態
一種比較流行的替代方法是在每個地域部署一個集群，然后設法對多個集群進行必要的編排。

對 Kubernetes 來說，跨越多個地域（Region）部署工作負載，這是個有趣的挑戰。雖然從技術上來說，我們可以用分布在多個地域的節點創建集群，但因為會造成額外的延遲，通常并不建議這樣做。

一種比較流行的替代方法是在每個地域部署一個集群，然后設法對多個集群進行必要的編排。

本文將介紹如何：

  1. 分別在北美、歐洲和東南亞各自創建一個集群。
  2. 創建第四個集群，將其作為上述三個集群的編排器。
  3. 設置一個將三個集群連接在一起的網絡，從而實現跨集群的無縫通信。

本文涉及的操作均可通過腳本實現，只需最少量人工介入即可適用于 Terraform。相關代碼請訪問 LearnK8s GitHub。

慶祝 Linode 加入 Akamai 解決方案大家庭，現在注冊 Linode，就可免費獲得價值 100 美元的使用額度，可以隨意使用 Linode 云平臺提供的各種服務。立即點擊這里了解詳情并注冊吧↓↓↓

出海云服務，Akamai 是您的不二之選！

創建集群管理器

首先創建用于管理其余集群的集群。我們可以通過下列命令創建該集群并保存 Kubeconfig 文件。

bash
$ linode-cli lke cluster-create \
 --label cluster-manager \
 --region eu-west \
 --k8s_version 1.23
$ linode-cli lke kubeconfig-view "insert cluster id here" --text | tail +2 | base64 -d > kubeconfig-cluster-manager

隨后可通過下列命令驗證安裝過程已成功完成：

bash
$ kubectl get pods -A --kubecnotallow=kubeconfig-cluster-manager

我們還需要在集群管理器中安裝 Karmada，這個管理系統可以幫助我們跨越多個 Kubernetes 集群或多個云平臺運行自己的云原生應用程序。Karmada 是一種安裝在集群管理器中的控制平面，其他集群中需要安裝代理程序。

該控制平面包含三個組件：

  1. 一個 API 服務器（API Server）
  2. 一個控制器管理器（Controller Manager）
  3. 一個調度器（Scheduler）


是否看起來覺得很熟悉？這是因為它與 Kubernetes 控制平面功能其實是相同組件，只不過 Karmada 能適用于多種集群。

理論部分說的差不多了，接下來開始看看具體要用的代碼。我們可以使用 Helm 安裝 Karmada API 服務器。為此可使用下列命令添加 Helm 倉庫：

bash
$ helm repo add karmada-charts https://raw.githubusercontent.com/karmada-io/karmada/master/charts
$ helm repo list
NAME URL
karmada-charts https://raw.githubusercontent.com/karmada-io/karmada/master/charts

由于 Karmada API 服務器必須能被所有其他集群訪問，因此我們必須：

  1. 從節點上將其暴露出來；并且
  2. 確保連接是可信任的。

因此首先需要通過下列命令獲取承載了控制平面的節點的 IP 地址：

bash
kubectl get nodes -o jsnotallow='{.items[0].status.addresses[?(@.type==\"ExternalIP\")].address}' \
 --kubecnotallow=kubeconfig-cluster-manager

隨后即可用下列命令安裝 Karmada 控制平面：

bash
$ helm install karmada karmada-charts/karmada \
 --kubecnotallow=kubeconfig-cluster-manager \
 --create-namespace --namespace karmada-system \
 --versinotallow=1.2.0 \
 --set apiServer.hostNetwork=false \
 --set apiServer.serviceType=NodePort \
 --set apiServer.nodePort=32443 \
 --set certs.auto.hosts[0]="kubernetes.default.svc" \
 --set certs.auto.hosts[1]="*.etcd.karmada-system.svc.cluster.local" \
 --set certs.auto.hosts[2]="*.karmada-system.svc.cluster.local" \
 --set certs.auto.hosts[3]="*.karmada-system.svc" \
 --set certs.auto.hosts[4]="localhost" \
 --set certs.auto.hosts[5]="127.0.0.1" \
 --set certs.auto.hosts[6]="<insert the IP address of the node>"

安裝完成后，即可通過下列命令獲得 Kubeconfig 并連接到 Karmada API：

bash
kubectl get secret karmada-kubeconfig \
 --kubecnotallow=kubeconfig-cluster-manager \
 -n karmada-system \
 -o jsnotallow={.data.kubeconfig} | base64 -d > karmada-config

不過為什么這里要用另一個 Kubeconfig 文件？

按照設計，Karmada API 是為了取代標準的 Kubernetes API，同時依然提供了用戶需要的全部功能。換句話說，我們可以借助 kubectl 創建橫跨多個集群的部署。

在測試 Karmada API 和 kubectl 之前，還需要調整 Kubeconfig 文件。默認情況下生成的 Kubeconfig 只能在集群網絡的內部使用。不過我們只需調整這幾行內容就可以消除這一限制：

yaml
apiVersion: v1
kind: Config
clusters:
 - cluster:
 certificate-authority-data: LS0tLS1CRUdJTi…
 insecure-skip-tls-verify: false
 server: https://karmada-apiserver.karmada-system.svc.cluster.local:5443 # <- this works only in the cluster
 name: karmada-apiserver
# truncated

請將之前獲取的節點 IP 地址替換進去：

yaml
apiVersion: v1
kind: Config
clusters:
 - cluster:
 certificate-authority-data: LS0tLS1CRUdJTi…
 insecure-skip-tls-verify: false
 server: https://<node's IP address>:32443 # <- this works from the public internet
 name: karmada-apiserver
# truncated

接下來就可以開始測試 Karmada 了。

安裝 Karmada 代理程序

運行下列命令檢索所有部署和所有集群：

bash
$ kubectl get clusters,deployments --kubecnotallow=karmada-config
No resources found

可想而知，目前沒有任何部署，也沒有任何額外的集群。我們可以添加幾個集群并將其連接到 Karmada 控制平面。

請重復執行下列命令三次：

bash
linode-cli lke cluster-create \
 --label <insert-cluster-name> \
 --region <insert-region> \
 --k8s_version 1.23
linode-cli lke kubeconfig-view "insert cluster id here" --text | tail +2 | base64 -d > kubeconfig-<insert-cluster-name>

執行時請分別使用如下的值：

  1. Cluster name eu, region eu-west 以及 kubeconfig file kubeconfig-eu
  2. Cluster name ap, region ap-south 以及 kubeconfig file kubeconfig-ap
  3. Cluster name us, region us-west 以及 kubeconfig file kubeconfig-us

隨后通過下列命令確認集群已經成功創建：

bash
$ kubectl get pods -A --kubecnotallow=kubeconfig-eu
$ kubectl get pods -A --kubecnotallow=kubeconfig-ap
$ kubectl get pods -A --kubecnotallow=kubeconfig-us

接下來要將這些集群加入 Karmada 集群。Karmada 需要在其他每個集群中使用代理程序來協調控制平面的部署。

我們可以使用 Helm 安裝 Karmada 代理程序并將其鏈接至集群管理器：

bash
$ helm install karmada karmada-charts/karmada \
 --kubecnotallow=kubeconfig-<insert-cluster-name> \
 --create-namespace --namespace karmada-system \
 --versinotallow=1.2.0 \
 --set installMode=agent \
 --set agent.clusterName=<insert-cluster-name> \
 --set agent.kubeconfig.caCrt=<karmada kubeconfig certificate authority> \
 --set agent.kubeconfig.crt=<karmada kubeconfig client certificate data> \
 --set agent.kubeconfig.key=<karmada kubeconfig client key data> \
 --set agent.kubeconfig.server=https://<insert node's IP address>:32443 \

上述命令同樣需要重復三次，每次分別插入下列變量：

  1. 集群名稱：分別為 eu、ap 和 us。
  2. 集群管理器的證書授權機構。我們可以在 karmada-config 文件的 clusters [0].cluster ['certificate-authority-data'] 中找到該值，這些值可以通過 base64 進行解碼。
  3. 用戶的客戶端證書數據。我們可以在 karmada-config 文件的 users [0].user ['client-certificate-data'] 中找到該值，這些值可以通過 base64 進行解碼。
  4. 用戶的客戶端密鑰數據。我們可以在 karmada-config 文件的 users [0].user ['client-key-data'] 中找到該值，這些值可以通過 base64 進行解碼。
  5. 承載 Karmada 控制平面的節點的 IP 地址。

隨后可以運行下列命令來驗證安裝是否成功完成：

bash
$ kubectl get clusters --kubecnotallow=karmada-config
NAME VERSION MODE READY
eu v1.23.8 Pull True
ap v1.23.8 Pull True
us v1.23.8 Pull True

借助 Karmada Policies 編排多集群部署

只要配置正確無誤，我們即可將工作負載提交給 Karmada，由它將任務分發給其他集群。

為了進行測試，我們首先需要創建一個部署：

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: hello
spec:
 replicas: 3
 selector:
 matchLabels:
 app: hello
 template:
 metadata:
 labels:
 app: hello
 spec:
 containers:
 - image: stefanprodan/podinfo
 name: hello
---
apiVersion: v1
kind: Service
metadata:
 name: hello
spec:
 ports:
 - port: 5000
 targetPort: 9898
 selector:
 app: hello

隨后通過下列命令將該部署提交至 Karmada API 服務器：

bash
$ kubectl apply -f deployment.yaml --kubecnotallow=karmada-config

該部署包含三個副本，那么是否可以平均分發給這三個集群？一起來驗證一下：

bash
$ kubectl get deployments --kubecnotallow=karmada-config
NAME READY UP-TO-DATE AVAILABLE
hello 0/3 0 0

Karmada 為何沒有創建 Pod？先來看看這個部署：

bash
$ kubectl describe deployment hello --kubecnotallow=karmada-config
Name: hello
Namespace: default
Selector: app=hello
Replicas: 3 desired | 0 updated | 0 total | 0 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Events:
 Type Reason From Message
 ---- ------ ---- -------
 Warning ApplyPolicyFailed resource-detector No policy match for resource

Karmada 并不知道該如何處理這個部署，因為我們尚未指定策略。

Karmada 調度器會使用策略將工作負載分配給集群。那么我們就定義一個簡單的策略，為每個集群分配一個副本：

yaml
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
 name: hello-propagation
spec:
 resourceSelectors:
 - apiVersion: apps/v1
 kind: Deployment
 name: hello
 - apiVersion: v1
 kind: Service
 name: hello
 placement:
 clusterAffinity:
 clusterNames:
 - eu
 - ap
 - us
 replicaScheduling:
 replicaDivisionPreference: Weighted
 replicaSchedulingType: Divided
 weightPreference:
 staticWeightList:
 - targetCluster:
 clusterNames:
 - us
 weight: 1
 - targetCluster:
 clusterNames:
 - ap
 weight: 1
 - targetCluster:
 clusterNames:
 - eu
 weight: 1

并用下列命令將該策略提交給集群：

bash
$ kubectl apply -f policy.yaml --kubecnotallow=karmada-config

然后再來看看部署和 Pod：

bash
$ kubectl get deployments --kubecnotallow=karmada-config
NAME READY UP-TO-DATE AVAILABLE
hello 3/3 3 3
$ kubectl get pods --kubecnotallow=kubeconfig-eu
NAME READY STATUS RESTARTS
hello-5d857996f-hjfqq 1/1 Running 0
$ kubectl get pods --kubecnotallow=kubeconfig-ap
NAME READY STATUS RESTARTS
hello-5d857996f-xr6hr 1/1 Running 0
$ kubectl get pods --kubecnotallow=kubeconfig-us
NAME READY STATUS RESTARTS
hello-5d857996f-nbz48 1/1 Running 0

Karmada 會為每個集群分配一個 Pod，因為策略中為每個集群定義了相等的權重。

我們用下列命令將該部署擴展為 10 個副本：

bash
$ kubectl scale deployment/hello --replicas=10 --kubecnotallow=karmada-config

隨后查看 Pod 會看到如下的結果：

bash
$ kubectl get deployments --kubecnotallow=karmada-config
NAME READY UP-TO-DATE AVAILABLE
hello 10/10 10 10
$ kubectl get pods --kubecnotallow=kubeconfig-eu
NAME READY STATUS RESTARTS
hello-5d857996f-dzfzm 1/1 Running 0
hello-5d857996f-hjfqq 1/1 Running 0
hello-5d857996f-kw2rt 1/1 Running 0
hello-5d857996f-nz7qz 1/1 Running 0
$ kubectl get pods --kubecnotallow=kubeconfig-ap
NAME READY STATUS RESTARTS
hello-5d857996f-pd9t6 1/1 Running 0
hello-5d857996f-r7bmp 1/1 Running 0
hello-5d857996f-xr6hr 1/1 Running 0
$ kubectl get pods --kubecnotallow=kubeconfig-us
NAME READY STATUS RESTARTS
hello-5d857996f-nbz48 1/1 Running 0
hello-5d857996f-nzgpn 1/1 Running 0
hello-5d857996f-rsp7k 1/1 Running 0

隨后修改策略，讓 EU 和 US 集群各承載 40% 的 Pod，讓 AP 集群只承載 20%。

yaml
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
 name: hello-propagation
spec:
 resourceSelectors:
 - apiVersion: apps/v1
 kind: Deployment
 name: hello
 - apiVersion: v1
 kind: Service
 name: hello
 placement:
 clusterAffinity:
 clusterNames:
 - eu
 - ap
 - us
 replicaScheduling:
 replicaDivisionPreference: Weighted
 replicaSchedulingType: Divided
 weightPreference:
 staticWeightList:
 - targetCluster:
 clusterNames:
 - us
 weight: 2
 - targetCluster:
 clusterNames:
 - ap
 weight: 1
 - targetCluster:
 clusterNames:
 - eu
 weight: 2

并通過下列命令提交策略：

bash
$ kubectl apply -f policy.yaml --kubecnotallow=karmada-config

接著可以看到，Pod 的分配情況也酌情產生了變化：

bash
$ kubectl get pods --kubecnotallow=kubeconfig-eu
NAME READY STATUS RESTARTS AGE
hello-5d857996f-hjfqq 1/1 Running 0 6m5s
hello-5d857996f-kw2rt 1/1 Running 0 2m27s
$ kubectl get pods --kubecnotallow=kubeconfig-ap
hello-5d857996f-k9hsm 1/1 Running 0 51s
hello-5d857996f-pd9t6 1/1 Running 0 2m41s
hello-5d857996f-r7bmp 1/1 Running 0 2m41s
hello-5d857996f-xr6hr 1/1 Running 0 6m19s
$ kubectl get pods --kubecnotallow=kubeconfig-us
hello-5d857996f-nbz48 1/1 Running 0 6m29s
hello-5d857996f-nzgpn 1/1 Running 0 2m51s
hello-5d857996f-rgj9t 1/1 Running 0 61s
hello-5d857996f-rsp7k 1/1 Running 0 2m51s

Karmada 支持通過多種策略分配工作負載，更多高級用例可以參考文檔。

Pod 在三個集群中運行，但我們該如何訪問？

先來看看 Karmada 中的服務：

bash
$ kubectl describe service hello --kubecnotallow=karmada-config
Name: hello
Namespace: default
Labels: propagationpolicy.karmada.io/name=hello-propagation
 propagationpolicy.karmada.io/namespace=default
Selector: app=hello
Type: ClusterIP
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.105.24.193
IPs: 10.105.24.193
Port: <unset> 5000/TCP
TargetPort: 9898/TCP
Events:
 Type Reason Message
 ---- ------ -------
 Normal SyncSucceed Successfully applied resource(default/hello) to cluster ap
 Normal SyncSucceed Successfully applied resource(default/hello) to cluster us
 Normal SyncSucceed Successfully applied resource(default/hello) to cluster eu
 Normal AggregateStatusSucceed Update resourceBinding(default/hello-service) with AggregatedStatus successfully.
 Normal ScheduleBindingSucceed Binding has been scheduled
 Normal SyncWorkSucceed Sync work of resourceBinding(default/hello-service) successful.

這些服務被部署在全部的三個集群中，但彼此之間并未連接。

盡管 Karmada 可以管理多個集群，但它并未提供任何網絡機制將這三個集群連接在一起。換句話說，Karmada 是一種跨越多個集群編排部署的好工具，但我們需要通過其他機制讓這些集群相互通信。

使用 Istio 連接多個集群

Istio 通常被用于控制同一個集群中應用程序之間的網絡流量，它可以檢查所有傳入和傳出的請求，并通過 Envoy 以代理的方式發送這些請求。

Istio 控制平面負責更新并收集來自這些代理的指標，還可以發出指令借此轉移流量。


因此我們可以用 Istio 攔截到特定服務的所有流量，并將其重定向至三個集群之一。這就是所謂的 Istio 多集群配置。

理論知識這就夠了，接下來親自試試吧。首先需要在三個集群中安裝 Istio。雖然安裝方法很多，但 Helm 最方便：

bash
$ helm repo add istio https://istio-release.storage.googleapis.com/charts
$ helm repo list
NAME URL
istio https://istio-release.storage.googleapis.com/charts

我們可以用下列命令將 Istio 安裝給三個集群：

bash
$ helm install istio-base istio/base \
 --kubecnotallow=kubeconfig-<insert-cluster-name> \
 --create-namespace --namespace istio-system \
 --versinotallow=1.14.1

請將 cluster-name 分別替換為 ap、eu 和 us，并將該命令同樣執行三遍。

Base chart 將只安裝通用資源，例如 Roles 和 RoleBindings。實際的安裝會被打包到 istiod chart 中。但在執行該操作前，我們首先需要配置 Istio Certificate Authority (CA)，以確保這些集群可以相互連接和信任。

請在一個新目錄中使用下列命令克隆 Istio 代碼庫：

bash
$ git clone https://github.com/istio/istio

創建一個 certs 文件夾并進入該目錄：

bash
$ mkdir certs
$ cd certs

使用下列命令創建根證書：

bash
$ make -f ../istio/tools/certs/Makefile.selfsigned.mk root-ca

該命令將生成下列文件：

  1. root-cert.pem：生成的根證書
  2. root-key.pem：生成的根密鑰
  3. root-ca.conf：供 OpenSSL 生成根證書的配置
  4. root-cert.csr：為根證書生成的 CSR

對于每個集群，還需要為 Istio Certificate Authority 生成一個中間證書和密鑰：

bash
$ make -f ../istio/tools/certs/Makefile.selfsigned.mk cluster1-cacerts
$ make -f ../istio/tools/certs/Makefile.selfsigned.mk cluster2-cacerts
$ make -f ../istio/tools/certs/Makefile.selfsigned.mk cluster3-cacerts

上述命令會在名為 cluster1、cluster2 和 cluster3 的目錄下生成下列文件：

bash
$ kubectl create secret generic cacerts -n istio-system \
 --kubecnotallow=kubeconfig-<cluster-name>
 --from-file=<cluster-folder>/ca-cert.pem \
 --from-file=<cluster-folder>/ca-key.pem \
 --from-file=<cluster-folder>/root-cert.pem \
 --from-file=<cluster-folder>/cert-chain.pem

我們需要使用下列變量執行這些命令：

| cluster name | folder name |
| :----------: | :---------: |
| ap | cluster1 |
| us | cluster2 |
| eu | cluster3 |

上述操作完成后，可以安裝 istiod 了：

bash
$ helm install istiod istio/istiod \
 --kubecnotallow=kubeconfig-<insert-cluster-name> \
 --namespace istio-system \
 --versinotallow=1.14.1 \
 --set global.meshID=mesh1 \
 --set global.multiCluster.clusterName=<insert-cluster-name> \
 --set global.network=<insert-network-name>

請使用下列變量將上述命令重復執行三遍：

| cluster name | network name |
| :----------: | :----------: |
| ap | network1 |
| us | network2 |
| eu | network3 |

我們還可以使用拓撲注釋來標記 Istio 的命名空間：

bash
$ kubectl label namespace istio-system topology.istio.io/network=network1 --kubecnotallow=kubeconfig-ap
$ kubectl label namespace istio-system topology.istio.io/network=network2 --kubecnotallow=kubeconfig-us
$ kubectl label namespace istio-system topology.istio.io/network=network3 --kubecnotallow=kubeconfig-eu

至此幾乎就快完成了。

通過東西網關為流量創建隧道

接下來我們還需要：

  1. 一個網關，借此通過隧道將流量從一個集群發送到另一個
  2. 一種機制，借此發現其他集群中的 IP 地址

我們可以使用 Helm 安裝網關：

bash
$ helm install eastwest-gateway istio/gateway \
 --kubecnotallow=kubeconfig-<insert-cluster-name> \
 --namespace istio-system \
 --versinotallow=1.14.1 \
 --set labels.istio=eastwestgateway \
 --set labels.app=istio-eastwestgateway \
 --set labels.topology.istio.io/network=istio-eastwestgateway \
 --set labels.topology.istio.io/network=istio-eastwestgateway \
 --set networkGateway=<insert-network-name> \
 --set service.ports[0].name=status-port \
 --set service.ports[0].port=15021 \
 --set service.ports[0].targetPort=15021 \
 --set service.ports[1].name=tls \
 --set service.ports[1].port=15443 \
 --set service.ports[1].targetPort=15443 \
 --set service.ports[2].name=tls-istiod \
 --set service.ports[2].port=15012 \
 --set service.ports[2].targetPort=15012 \
 --set service.ports[3].name=tls-webhook \
 --set service.ports[3].port=15017 \
 --set service.ports[3].targetPort=15017 \

請使用下列變量將上述命令執行三遍：

| cluster name | network name |
| :----------: | :----------: |
| ap | network1 |
| us | network2 |
| eu | network3 |

隨后對于每個集群，請使用下列資源暴露一個網關：

yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
 name: cross-network-gateway
spec:
 selector:
 istio: eastwestgateway
 servers:
 - port:
 number: 15443
 name: tls
 protocol: TLS
 tls:
 mode: AUTO_PASSTHROUGH
 hosts:
 - "*.local"

并使用下列命令將文件提交至集群：

bash
$ kubectl apply -f expose.yaml --kubecnotallow=kubeconfig-eu
$ kubectl apply -f expose.yaml --kubecnotallow=kubeconfig-ap
$ kubectl apply -f expose.yaml --kubecnotallow=kubeconfig-us

對于發現機制，我們需要共享每個集群的憑據。這是因為集群并不知道彼此的存在。

為了發現其他 IP 地址，集群必須能彼此訪問，并將這些集群注冊為流量的可能目的地。為此我們必須使用其他集群的 kubeconfig 文件創建一個 Kubernetes secret。Istio 可以借此連接其他集群，發現端點，并指示 Envoy 代理轉發流量。

我們需要三個 Secret：

yaml
apiVersion: v1
kind: Secret
metadata:
 labels:
 istio/multiCluster: true
 annotations:
 networking.istio.io/cluster: <insert cluster name>
 name: "istio-remote-secret-<insert cluster name>"
type: Opaque
data:
 <insert cluster name>: <insert cluster kubeconfig as base64>

請使用下列變量創建這三個 Secret：

| cluster name | secret filename | kubeconfig |
| :----------: | :-------------: | :-----------: |
| ap | secret1.yaml | kubeconfig-ap |
| us | secret2.yaml | kubeconfig-us |
| eu | secret3.yaml | kubeconfig-eu |

接下來需要向集群提交 Secret，但是請注意，不要將 AP 的 Secret 提交給 AP 集群。

為此需要執行下列命令：

bash
$ kubectl apply -f secret2.yaml -n istio-system --kubecnotallow=kubeconfig-ap
$ kubectl apply -f secret3.yaml -n istio-system --kubecnotallow=kubeconfig-ap
$ kubectl apply -f secret1.yaml -n istio-system --kubecnotallow=kubeconfig-us
$ kubectl apply -f secret3.yaml -n istio-system --kubecnotallow=kubeconfig-us
$ kubectl apply -f secret1.yaml -n istio-system --kubecnotallow=kubeconfig-eu
$ kubectl apply -f secret2.yaml -n istio-system --kubecnotallow=kubeconfig-eu

至此，大部分操作已經完成，我們可以開始測試整個配置了。

測試多集群網絡連接

首先為一個睡眠中的 Pod 創建一個部署。我們可以使用該 Pod 向剛才創建的 Hello 部署發出請求：

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: sleep
spec:
 selector:
 matchLabels:
 app: sleep
 template:
 metadata:
 labels:
 app: sleep
 spec:
 terminationGracePeriodSeconds: 0
 containers:
 - name: sleep
 image: curlimages/curl
 command: ["/bin/sleep", "3650d"]
 imagePullPolicy: IfNotPresent
 volumeMounts:
 - mountPath: /etc/sleep/tls
 name: secret-volume
 volumes:
 - name: secret-volume
 secret:
 secretName: sleep-secret
 optional: true

請用下列命令創建部署：

bash
$ kubectl apply -f sleep.yaml --kubecnotallow=karmada-config

因為該部署尚未指定策略，Karmada 將不處理該部署，使其處于 “未決” 狀態。我們可以修改策略以包含該部署：

yaml
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
 name: hello-propagation
spec:
 resourceSelectors:
 - apiVersion: apps/v1
 kind: Deployment
 name: hello
 - apiVersion: v1
 kind: Service
 name: hello
 - apiVersion: apps/v1
 kind: Deployment
 name: sleep
 placement:
 clusterAffinity:
 clusterNames:
 - eu
 - ap
 - us
 replicaScheduling:
 replicaDivisionPreference: Weighted
 replicaSchedulingType: Divided
 weightPreference:
 staticWeightList:
 - targetCluster:
 clusterNames:
 - us
 weight: 2
 - targetCluster:
 clusterNames:
 - ap
 weight: 2
 - targetCluster:
 clusterNames:
 - eu
 weight: 1

使用下列命令應用該策略：

bash
$ kubectl apply -f policy.yaml --kubecnotallow=karmada-config

要了解該 Pod 被部署到哪里，可以使用下列命令：

bash
$ kubectl get pods --kubecnotallow=kubeconfig-eu
$ kubectl get pods --kubecnotallow=kubeconfig-ap
$ kubectl get pods --kubecnotallow=kubeconfig-us

接下來，假設該 Pod 被部署到 US 集群，請執行下列命令：

bash
for i in {1..10}
do
 kubectl exec --kubecnotallow=kubeconfig-us -c sleep \
 "$(kubectl get pod --kubecnotallow=kubeconfig-us -l \
 app=sleep -o jsnotallow='{.items[0].metadata.name}')" \
 -- curl -sS hello:5000 | grep REGION
done

我們將會發現，響應會來自不同地域的不同 Pod！搞定！

總結

該配置其實非常基礎，缺乏真實環境中可能需要的其他很多功能：

  1. 我們可以從每個集群暴露出一個 Istio 入口以攝入流量
  2. 我們可以使用 Istio 進行流量塑型，這樣就會優先進行本地處理
  3. 還可以使用 Istio 策略強制規則定義流量如何在不同集群之間流動

這篇文章的內容感覺還行吧？有沒有想要立即在 Linode 平臺上親自嘗試一下？別忘了，現在注冊可以免費獲得價值 100 美元的使用額度，快點自己動手體驗本文介紹的功能和服務吧↓↓↓

出海云服務，Akamai 是您的不二之選！

歡迎關注Akamai，第一時間了解高可用的 MySQL/MariaDB 參考架構，以及豐富的應用程序示例。

責任編輯：張燕妮
技術方案
相關推薦

2014-03-31 15:32:36

AndroidNDK開發

2022-03-21 18:27:38

Linux計算機函數

2020-06-27 17:33:42

云計算技術安全

2023-07-30 16:09:38

數字經濟數字化轉型

2018-07-30 09:00:49

技術管理實踐

2017-08-09 14:49:03

WebHTTPS瀏覽器

2015-06-24 10:32:13

訊鳥云計算會展

2016-06-08 13:42:08

2013-02-22 09:49:43

大數據谷歌大數據全球技術峰會

2014-03-14 09:35:56

內存優化軟件內存優化

2022-08-01 10:31:40

KubernetesIPLinux

2020-09-30 10:40:56

人工智能AI

2021-08-18 10:45:44

網絡AI智能

2023-09-06 09:00:00

2015-06-04 09:38:51

數據中心PUE

2022-07-11 12:37:15

安全運營網絡攻擊

2022-09-25 11:46:52

瀏覽器擴展程序廣告攔截器

2022-09-28 07:19:35

瀏覽器安全保證惡意擴展

2025-04-03 07:00:00

網絡安全物聯網安全智能安全

2018-02-09 10:20:47

點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 麻豆精品国产91久久久久久 | 国产高清久久久 | 午夜男人天堂 | 日本色高清 | 久久精品免费观看 | 国产成人久久精品 | 欧美久久视频 | 91精品国产综合久久婷婷香蕉 | 日韩一区二区av | 精品国产视频 | 亚洲一区二区在线播放 | 99久久精品免费 | 国产精品视频入口 | 欧美在线一区二区三区 | 欧美一区二区三区在线观看 | 国产美女视频黄a视频免费 国产精品福利视频 | 午夜电影网站 | 国产精品自在线 | 日韩精品一区二区三区四区视频 | 国产日韩欧美一区 | 欧美精品片 | 亚洲一区久久 | 成人亚洲精品久久久久软件 | 黄色成人在线观看 | 欧美国产视频一区二区 | 老熟女毛片 | 日本精a在线观看 | 91精品国产乱码久久久久久久久 | 香蕉久久a毛片 | 91亚洲国产精品 | 亚洲黄色视屏 | 91av在线视频观看 | 免费成人毛片 | 国产精品视频一区二区三区四蜜臂 | 2019天天干夜夜操 | 欧美www在线观看 | 欧美一区二区大片 | 日本小电影在线 | 亚洲婷婷一区 | 亚洲精品自在在线观看 | 黄色网址在线免费观看 |