** 版本 1.8.0 官方文档certificate management 中的 “Plug in CA Certificates” 对此有了更好的描述。** 部署模型 Replicated control planes Shared control plane (single and multiple networks) 环境 istio 1.6.3 k8s 1.16.3 root-ca 为什么需要root-ca？多集群双向认证的必要条件，即使当前是单独部署，考虑到未来多集群的可能性，也应当做root-ca，intermediate-ca的处理。 官方文档有明确的提醒：不可将“sample”的root-ca用于生产，需要构建私有的root-ca。官方仓库有提供两个工具帮忙我们生成root-ca。 直接用 Makefile samples/certs/Makefile, 这个文件在master分支是没有的，在发布tag上有。然后执行以下命令, 会在当前目录生成4个文件 $ make root-ca generating root-key.pem Generating RSA private key, 4096 bit long modulus ..........................................................................++ ...........................................................++ e is 65537 (0x10001) generating root-cert.csr generating root-cert.pem Signature ok subject=/O=Istio/CN=Root CA Getting Private key $ tree . . ├── Makefile ├── root-ca.

本文的内容已经过时，未来的发行版将删除addon，请详见官方的博客Reworking our Addon Integrations，addon 整合已经不是社区未来的方向，所以可以极早向上游部署方式看齐，这是一个好的方向。 本文将部署 Istio 的监控，观测附加组件 grafana、tracing、kiali 。标题中使用了“体验”这个词，所以本文所做的练习只是用于体验，切不可用于生产，且行文的表述都是基于“体验”这个前提，体验完后，请务必清理。这种建议主要基于以下考虑: 安全。在没有应用“认证”、“授权”机制前，这些服务裸奔在公网是危险的，即使有的系统有帐密。 存储。这些服务都是有状态的，涉及状态数据的存储，如：promethues、grafana、kiali、tracing。这些 Pod 一旦重建，数据就会丢失。一般地，需要我们适配 k8s 标准化过的存储机制，如：storageClass、pv、pvc等。 组件部署 查看支持的 addonComponents，以及默认的配置值。 $ istioctl profile dump --config-path addonComponents 2020-06-10T01:37:35.653332Z info proto: tag has too few fields: "-" grafana: enabled: false k8s: replicaCount: 1 istiocoredns: enabled: false kiali: enabled: false k8s: replicaCount: 1 prometheus: enabled: true k8s: replicaCount: 1 tracing: enabled: false grafana 在 override 文件中添加 addonComponents.grafana.enabled=true 项后，应用到集群。 apiVersion: install.istio.io/v1alpha1 kind: IstioOperator metadata: namespace: istio-system spec: profile: default addonComponents: grafana: enabled: true components: ingressGateways: - name: istio-ingressgateway enabled: true k8s: serviceAnnotations: # https://cloud.

istio 1.5.0 于北京时间2020年3月6日发布，该版本在架构上有很大的变化(Istio 1.5 新特性解读)，做出这些改变的原因及其重大意义这里不做赘述，有大量的文章做了阐述，本文聚焦于探索 istio-1.5.0 的行为。文中的练习是在腾讯云的容器服务 tke-1.16.3 上进行的，会涉及到一些云平台相关的实现。 安装istio 使用 istioctl 安装是官方推荐的方式(Customizable Install with Istioctl)，helm 安装方式已经被标记为 deprecated，且已经不支持 helm3。istioctl 安装实践，一般选择一个profile（生产环境，社区推荐基于 default），然后用自定义的值进行覆盖，一般而言，我们只需要编写这个 override 文件(这里的文件名是 profile-override-default.yaml)，不需要修改 charts （当然charts是可以被修改的）。 apiVersion: install.istio.io/v1alpha1 kind: IstioOperator metadata: namespace: istio-system spec: profile: default 另一面，override 文件中的项，以及项的节点层次怎么找呢？建议两种方式：1，通过 istioctl profile dump default 命令可以打印一些，但不够全；2，查看 charts （install/kubernetes/operator/charts/） 里各子项目的 values 文件定义，这种方式最可靠，对值的行为还可以辅以 templates 文件更深入的了解，推荐这种。 有了 override 文件后，就可以使用下面的命令生成 manifest，manifest 是 k8s 的定义。建议把 override 文件和生成的 manifest 文件都通过版本控制工具维护起来，在每次对 override 操作后，对比前后的差异。 $ istioctl manifest generate -f profile-override-default.yaml > manifest-override-default.