在生产环境中运行Istio的十个建议

微信扫一扫,分享到朋友圈

在生产环境中运行Istio的十个建议

本文主要讲述有关生产环境运行Istio的十个技巧,在一定程度上可以提升你Istio和Envoy Proxy的能力。

  1. 使用 Kubectl Sniff 和Wireshark。 Sniff提供了一种抽象,使您可以侦听通过Wireshark进出Istio代理的数据包。 Sniff非常适合进行简单分析,使您能够将根本原因缩小到应用程序级和Envoy级问题。首先在IstioOperator CRD上启用特权模式 global.proxy.privileged = true ,然后将以下注释添加到您的部署中。
apiVersion: apps/v1
kind: Deployment
metadata:
name: reception
spec:
template:
metadata:
annotations:
sidecar.istio.io/capNetBindService: "true"

在Wireshark中,您可以捕获gRPC请求并根据它们进行过滤,然后“遵循”请求的生命周期来确定其进出。

2. 首先先熟悉Envoy。通过在本地docker-compose文件中运行Envoy来了解如何配置Envoy过滤器链,从而使更改(例如影子流量或WASM)原型更加容易。在将其转换为Istio配置的过程中,建立对Envoy的了解,将带来好处。

3. 认真阅读发行说明。值得重申的是,过去我们在发布说明上错过了主要更改。在之前的Istio升级过程中,我们错过了一个看似良性的更改,即对Envoy状态端口进行了修改(15020-> 15021),这使我们认为负载均衡器不健康。

4. 通过Istio operator使用Istioctl生成清单–我们最近从1.6-> 1.7进行了升级,并注意到该operator由于结构(EnvoyFilter)的更改而无法完成其控制循环。我们希望operator能够以向后兼容的方式处理此升级。生成的清单易于通过Istio Overlay API或Kustomize来处理未通过Operator CRD公开的字段(例如,服务注释)。

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: wasm-hmac
spec:
workloadSelector:
labels: # labels, not label
app: pubsub-gateway

5. 找到示例清单后,请确认示例与代理容器中的Envoy API/Protobuf版本一致。大致地记录了与最新Envoy关联的typed_config示例的一些关键功能。

patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.wasm
typed_config:
"@type": type.googleapis.com/udpa.type.v1.TypedStruct
type_url: type.googleapis.com/envoy.config.filter.http.wasm.v3.Wasm
value:
config:
name: "signature_auth"
root_id: "signature_auth"
configuration:
"@type": "type.googleapis.com/google.protobuf.Struct"
value:
signing_key: ""
signature_header: "X-My-Hmac-Header-SHA256"
vm_config:
runtime: "envoy.wasm.runtime.v8"
code:
local:
filename: "/etc/wasm/your-binary.wasm"
allow_precompiled: true

6. 如果您将Istio Ingress Gateway用作GKE上集群的入口,并且要启用HTTPS,请在Istio Ingress Gateway服务的单个上游设置一个Ingress对象。添加静态IP计算地址,托管证书和BackendConfig(以设置运行状况检查),以便您通过负载均衡器提供安全访问。这是有关此主题的教程。

7. 请求镜像是“生产中测试”的有力手段。如果您在安装中启用了此功能,但无法解释为什么下游服务拒绝请求,请查看host header。 Envoy将“-shadow”附加到host header 。如果您使用的是 香草Envoy ,则可以通过创建单独的侦听器来解决此问题。重写此header在Istio中并不完全可行,因此我们选择添加一个单独的Envoy部署以将header重写到我们的预期目标。

同样,如果您要使用istio-ingressgateway在边缘实现请求镜像,并希望进行集群镜像,请将本地服务名称和关键字 mesh 添加到您的虚拟服务中。

kind: VirtualService
metadata:
name: mirror-policy
namespace: your-app
spec:
gateways:
- istio-system/your-gateway
- mesh
hosts:
- 'your-service.your-app.svc.cluster.local'
- 'your-api.dot.com'

8. JWT验证提供了一个有趣的抽象,它允许您的服务知道它是否已通过身份验证。使用诸如Open Policy Agent之类的工具在工作负载上强制使用必需的标签,以确保所有服务上都带有身份验证标签。另外,当您在JWTRule上启用“outputPayloadToHeader”以传播上下文时,期望有效载荷在被服务占用时会丢失base64填充。

9. GRPC JSON转码是一种方便的抽象,可以节省工程师必须编写帮助程序代码以将JSON转码为GRPC的时间。但是,将更改部署到原型描述符的过程似乎有些笨拙。我们最初的解决方法包括base64编码原型描述符,并将其作为秘钥安装。由于Protobuf定义更改时,没有工程师希望对二进制文件进行base64编码,因此这种方法很快变得难以处理。一种稍微更优雅的方法是使用描述符构建容器镜像,并将其作为具有共享内存量的initContainer运行。在pod启动后,您的initContainer会将二进制文件复制到共享卷空间中,并且Istio代理容器可以访问它。

apiVersion: apps/v1
kind: Deployment
metadata:
name: reception
spec:
template:
metadata:
annotations: # only good for prototyping!
sidecar.istio.io/userVolumeMount: '[{"name":"my-cert", "mountPath":"/etc/envoy", "readonly":true}, {"name": "cache-volume", "mountPath":"/tmp"}]'
sidecar.istio.io/userVolume: '[{"name":"my-cert", "secret":{"secretName":"event-reception-pb"}}, {"name": "cache-volume", "emptyDir":{}}]'

10. Envoy提供了一种修改过滤器的虚拟主机特定配置的方法。用Istio术语来说,这意味着可以更改特定虚拟主机路径上现有过滤器功能的方式。此功能适用于特定过滤器,其中提到它们支持“按路由配置”,但不适用于WASM等过滤器。

如果您必须添加标签,则可能是pod模板规范标签,而不是部署标签。使用istioctl分析可为您解决问题。

PS: 本文属于翻译,原文

微信扫一扫,分享到朋友圈

在生产环境中运行Istio的十个建议

NVIDIA RTX 3060 Ti 真卡图像首次泄露 来自技嘉Eagle OC

上一篇

美国大选最新战况!川普再次打脸民调!

下一篇

你也可能喜欢

在生产环境中运行Istio的十个建议

长按储存图像,分享给朋友