1. 首頁 > 生活百科 > >

二 Istio：在Kubernetes(k8s)集群上安裝部署istio1.14( 三 )

生活百科

要切換到不同版本的 Istio CLI，我們可以運行 getmesh switch 命令：
[root@k8scloude1 ~]# getmeshswitch --version 1.9.5 --flavor tetrate --flavor-version 04.6 CA 集成我們沒有使用自簽的根證書，而是從 GCP CAS（證書授權服務）獲得一個中間的 Istio 證書授權（CA）來簽署工作負載證書 。
假設你已經配置了自己的 CAS 實例，可以用 CA 的參數創建一個 YAML 配置 。下面是 YAML 配置的一個例子：
providerName: "gcp" providerConfig:gcp:# 你在 GCP 上創建的證書授權的完整 CA 名稱casCAName: "projects/tetrate-io-istio/locations/us-west1/certificateAuthorities/tetrate-example-io" certificateParameters:secretOptions:istioCANamespace: "istio-system" # cacerts secret 所在的命名空間overrideExistingCACertsSecret: true # 重寫已存在的 cacerts secret，使用新的替換caOptions:validityDays: 365 # CA 到期前的有效天數keyLength: 2048 # 創建的 key 的比特數certSigningRequestParams: # x509.CertificateRequest；大部分字段省略subject:commonname: "tetrate.example.io"country:- "US"locality:- "Sunnyvale"organization:- "Istio"organizationunit:- "engineering"emailaddresses:- "youremail@example.io"配置完成后，你可以使用 gen-ca 命令來創建 cacert 。
[root@k8scloude1 ~]# getmesh gen-ca --config-file gcp-cas-config.yaml該命令在 istio-system 中創建 cacerts Kubernetes Secret 。為了讓 istiod 接受新的 cert，你必須重新啟動 istiod 。
如果你創建一個 sample 工作負載 ， 并檢查所使用的證書，你會發現是 CA 為工作負載發布的證書 。
Istio CA certs 集成可用于 GCP CA 服務和 AWS Private CA 服務 。
五.發現選擇器(Discovery Selectors)發現選擇器是 Istio 1.10 中引入的新功能之一 。發現選擇器允許我們控制 Istio 控制平面觀察和發送配置更新的命名空間 。
默認情況下，Istio 控制平面會觀察和處理集群中所有 Kubernetes 資源的更新 。服務網格中的所有 Envoy代理的配置方式是，它們可以到達服務網格中的每個工作負載，并接受與工作負載相關的所有端口的流量 。
例如，我們在不同的命名空間部署了兩個工作負載——foo 和 bar 。盡管我們知道 foo 永遠不會與 bar 通信 ， 反之亦然，但一個服務的端點將被包含在另一個服務的已發現端點列表中 。

二 Istio：在Kubernetes(k8s)集群上安裝部署istio1.14

文章插圖
如果我們運行 istioctl proxy-config 命令 ， 列出 foo 命名空間的 foo 工作負載可以看到的所有端點 ， 你會注意到一個名為 bar 的服務條目：
[root@k8scloude1 ~]# istioctl proxy-config endpoints deploy/foo.foo ENDPOINTSTATUSOUTLIER CHECKCLUSTER … 10.4.1.4:31400HEALTHYOKoutbound|31400||istio-ingressgateway.istio-system.svc.cluster.local 10.4.1.5:80HEALTHYOKoutbound|80||foo.foo.svc.cluster.local 10.4.2.2:53HEALTHYOKoutbound|53||kube-dns.kube-system.svc.cluster.local 10.4.4.2:8383HEALTHYOKoutbound|8383||istio-operator.istio-operator.svc.cluster.local 10.4.4.3:8080HEALTHYOKoutbound|80||istio-egressgateway.istio-system.svc.cluster.local 10.4.4.3:8443HEALTHYOKoutbound|443||istio-egressgateway.istio-system.svc.cluster.local 10.4.4.4:80HEALTHYOKoutbound|80||bar.bar.svc.cluster.local ...如果 Istio 不斷用集群中每個服務的信息來更新代理，即使這些服務是不相關的，我們可以想象這將如何拖累事情 。
如果這聽起來很熟悉，你可能知道已經有一個解決方案了——Sidecar 資源 。
我們將在后面的模塊中討論 Sidecar 資源 。
5.1 配置發現選擇器發現選擇器可以在 MeshConfig 中的 Mesh 層面上進行配置 。它們是一個 Kubernetes 選擇器的列表，指定了 Istio 在向 sidecar 推送配置時觀察和更新的命名空間的集合 。
就像 Sidecar 資源一樣，discoverySelectors 可以用來限制被 Istio 觀察和處理的項目數量 。
我們可以更新 IstioOperator 以包括 discoverySelectors 字段，如下所示：
apiVersion: install.istio.io/v1alpha1 kind: IstioOperator metadata:namespace: istio-systemname: istio-demo spec:meshConfig:discoverySelectors:- matchLabels:env: test上面的例子將 env=test 設置為一個匹配標簽 。這意味著標有 env=test 標簽的命名空間中的工作負載將被包含在 Istio 監控和更新的命名空間列表中 。
如果我們給 foo 命名空間貼上 env=test 標簽，然后列出端點，我們會發現現在配置中列出的端點沒有那么多 。這是因為我們標注的唯一命名空間是 foo 命名空間，這也是 Istio 控制平面觀察和發送更新的唯一命名空間 。

推薦閱讀