环境 istio 1.6.3 k8s 1.16.3 场景 需求与下述的两个用例完全一致：将请求的特定前缀删除后，再转发给后端应用，这是一个很普通的 rewrite 场景，下面的两个用例也给出了解决方案且有效。官方的文档HTTPRewrite，描述相当的简单，信息量很少，在排查问题的时候遇到困扰，好在找到了下面的两个用例，过程记录如下。 Rewrite url to the root in the gateway istio: VirtualService rewrite to the root url 目标 请求分发是否符合预期 rewrite 是否符合预期，不同的istio-proxy(istio-ingressgateway, sidecar)在这个过程中承担的角色和行为。 过程 打开envoy的accessLog，重建 istio-ingressgateway 工作负载、应用工作负载，以让这些pod里的istio-proxy 应用日志选项。 $ kubectl -n istio-system edit cm istio ...... # Set accessLogFile to empty string to disable access log. accessLogFile: "/dev/stdout" # 开启日志 ...... 以官方用例中的httpbin来做这个实验，只是对httpbin-gateway中的 VirtualService:httpbin 增加了rewrite选项，如下。这里要实现的意图与上文中 rewrite-url-to-root 的场景是一样的，解决方案也是使用的stackoverflow中描述的方案。 gateways: - httpbin-gateway http: + - match: + - uri: + prefix: /api + rewrite: + uri: " " + route: + - destination: + host: httpbin + port: + number: 8000 - route: - destination: host: httpbin 打开3个终端，观察行为。

** 版本 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.

环境 istio 1.5.2 多ingressGateway 什么场景会需要多个 ingressGateway 多租户。Istio 租户模型- Namespace tenancy 描述了“命名空间”租户模型，不同集群的相同 namespace 视为一个租户。这种模型下，各租户的资源应当是隔离的，ingressgateway和各种secret（如证书）就是租户的资源。 同一个租户，需要公共/私有的入口。私有ingressGateway 在公有云上可以理解为一个内网的lb，当有业务不在k8s集群内时，集群外的业务要访问集群内的业务，一般是通过这个内网的lb；多个云SP通过专线互联时，同一个云跨AZ时；这些都对应多集群网格的构建场景，私有的ingressGateway是非常必要的，特别是Gateway方式的多集群网格，更应该选择内网lb作为集群间互通的入口，而不是mTLS的公网gateway。 components.ingressGateways 好消息是：components.ingressGateways 是一个list, 可见设计意图里包含多个 ingreessgateway。相应的，components.egressGateways 也是同样的。 $ istioctl profile dump --config-path components.ingressGateways - enabled: true k8s: hpaSpec: maxReplicas: 5 metrics: - resource: name: cpu targetAverageUtilization: 80 type: Resource minReplicas: 1 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: istio-ingressgateway resources: limits: cpu: 2000m memory: 1024Mi requests: cpu: 100m memory: 128Mi strategy: rollingUpdate: maxSurge: 100% maxUnavailable: 25% name: istio-ingressgateway 坏消息是：上面定义的多个ingressgateway 的 label 不生效(截止1.

根据官方文档：认证 章节的描述，Istio 提供两种认证机制(PeerAuthentication，RequestAuthentication)，PeerAuthentication 解决工作负载间的问题，RequestAuthentication 解决用户端的问题。本文关注用 RequestAuthentication 来保护“裸”应用。以下是需要先从官网了解的相关知识： 认证 Request authentication 环境 istio 1.5.2 RequestAuthentication 先看看 manifest 长什么样子，下面是官网的一个样例，主要由两个字段构成 selector，jwtRules。 apiVersion: "security.istio.io/v1beta1" kind: "RequestAuthentication" metadata: name: "jwt-example" namespace: istio-system spec: selector: matchLabels: istio: ingressgateway jwtRules: - issuer: "testing@secure.istio.io" jwksUri: "https://raw.githubusercontent.com/istio/istio/master/security/tools/jwt/samples/jwks.json" Reference: Request authentication 描述了manifest 的完整定义。 Reference: JWTRule 描述了 jwtRules 的定义。 Selector selector 通过 label 机制选择适用该策略的目标工作负载。 您可以将JWT策略添加到入口网关（上面的样例就是）。 这通常用于为绑定到网关的所有服务而不是单个服务定义JWT策略。下面是官方文档的原文 You can also add a JWT policy to an ingress gateway (e.g., service istio-ingressgateway.istio-system.svc.cluster.local). This is often used to define a JWT policy for all services bound to the gateway, instead of for individual services.

在进行本节练习之前，先按照官方用例 Authorization on Ingress Gateway 完成 httpbin 的部署，httpbin 这个应用真的很好用。 $ kubectl apply -f samples/httpbin/httpbin.yaml -n test-mesh $ kubectl apply -f samples/httpbin/httpbin-gateway.yaml -n test-mesh 从公网访问 http://your-lb-ip/，预期显示的是 httbin 的 swagger ui。/ip，/anything，/headers 等 restful api 会给我们调试验证带来极大的帮助。如下面的 /anything 请求，其行为是 “Returns anything that is passed to request”。 $ curl http://your-lb-ip/anything { "args": {}, "data": "", "files": {}, "form": {}, "headers": { "Accept": "*/*", "Content-Length": "0", "Host": "your-lb-ip", "User-Agent": "curl/7.54.0", "X-B3-Parentspanid": "7d83460f9c0bb319", "X-B3-Sampled": "1", "X-B3-Spanid": "e2a3c9482108d0b5", "X-B3-Traceid": "149ddcb0970898197d83460f9c0bb319", "X-Envoy-Internal": "true", "X-Forwarded-Client-Cert": "By=spiffe://cluster.

本文的内容已经过时，未来的发行版将删除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.