二 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 通信，反之亦然，但一个服务的端点将被包含在另一个服务的已发现端点列表中。

文章插图
如果我们运行 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 控制平面观察和发送更新的唯一命名空间。