tencent cloud

文档反馈

Sidecar 注入与配置

最后更新时间:2023-12-26 11:45:21

    配置 Sidecar 自动注入

    TCM 当前支持在控制台为指定的 Namespace 开启 Sidecar 自动注入,开启后该 Namespace 下新创建的 workload 将会自动安装网格 Sidecar,由于注入是在 workload 创建过程中完成的,因此开启注入无法为已存在的 workload 自动安装 Sidecar,您可以通过重建 workload 完成 Sidecar 自动注入。
    以下是配置 Namespaces 级 Sidecar 自动注入的步骤:
    1. 登录 服务网格控制台,单击需要变更配置的网格 ID,进入网格的管理页面。
    
    
    2. 在服务列表页点击单击Sidecar 自动注入,进入 Sidecar 自动注入配置弹窗。
    
    
    3. 按需勾选需要 Sidecar 自动注入的 namespace,单击确定完成 Sidecar 自动注入配置。
    
    

    自定义 Sidecar 注入

    TCM 也支持您通过编辑 yaml 为特定的工作负载开启 Sidecar 自动注入,如有需要,您可以在 Pod 上添加 label:istio.io/rev:{istio 版本号}(注意 Sidecar 注入相关的标签设置,TCM 与 istio 默认语法略有区别),示例如下:
    
    
    
    如果您需要为已经开启了自动注入的 Namespace 下的特定 Pod 添加特例,使其不自动注入 Sidecar,可在 Pod label 中添加:sidecar.istio.io/inject="false"。Pod 级别的注入开关优先级高于 Namespace 级别,关于 Sidecar 自动注入的更多细节,请参考 Istio 文档 安装 sidecar

    不拦截指定网段的流量

    如果您不希望拦截某些流量,例如上传文件到 COS 对象存储存储的流量(169.254 开头的内网目标 IP),如果被拦截,且下载的文件较大,则可能导致 Sidecar 内存资源占用很高,因为 Sidecar 会缓存请求内容,出错自动重试时会复用请求内容。这时,您可以在网格基本信息页中的高级设置中配置“外部请求绕过Sidecar”,添加不希望拦截的网段。操作步骤如下:
    1. 登录 服务网格控制台,单击需要变更配置的网格 ID,进入网格的管理页面。
    2. 在基本信息页面,单击外部请求绕过Sidecar右侧的
    
    。如下图所示:
    
    
    3. 在“编辑外部请求绕过Sidecar”弹窗中,添加您不希望拦截的网段。如下图所示:
    
    
    4. 单击保存
    以上是全局配置,如果希望只针对某些工作负载,可以给 Pod 添加注解 traffic.sidecar.istio.io/excludeOutboundIPRanges 。详情可参考 注解列表
    
    
    

    控制 sidecar 启动顺序

    Kubernetes 拉起 Pod 的时候是各个容器同时拉起,使用 istio 的场景,因为流量会被 Sidecar 拦截,当遇到 Sidecar 比业务容器启动更慢的时候,业务容器刚启动时的网络请求将会失败,因为流量被 Sidecar 拦截但 Sidecar 还没启动就绪。比较常见的场景是:集群规模较大,Sidecar 启动时拉取 xds 较慢导致 Sidecar 启动较慢,而业务进程启动时要从注册中心拉取配置,由于流量被 Sidecar 拦截而 Sidecar 此时还无法处理流量导致配置拉取失败,然后业务进程报错退出,导致容器退出。
    主要有两种解决方案,第一种是让业务代码更健壮,启动时请求失败要不断重试,直至成功;第二种是让 Sidecar 先启动,等 Sidecar 就绪后再拉起业务容器。您可以参考以下步骤开启 Sidecar 就绪保障。
    1. 登录 服务网格控制台,单击需要变更配置的网格 ID,进入网格的管理页面。
    2. 在基本信息页面,单击 Sidecar 就绪保障右侧的
    
    。如下图所示:
    
    
    
    以上是全局配置,如果只想针对某些工作负载,可以为 Pod 添加如下注解:
    proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts" : true }'
    
    
    

    Sidecar 优雅终止

    业务发版时,工作负载滚动更新,Pod 在终止过程中,Sidecar 默认只等待几秒然后就会强制停止,如果业务请求本身耗时较长,或者使用长连接,可能会导致部分正常业务请求和连接中断,我们希望 Sidecar 会等待存量的业务请求和连接结束再退出以实现优雅终止。自 istio 1.12 开始,Sidecar 支持了 EXIT_ON_ZERO_ACTIVE_CONNECTIONS这个环境变量,作用就是等待 Sidecar “排水” 完成,在响应时,也通知客户端去关闭长连接(对于 HTTP1 响应 “Connection: close” 这个头,对于 HTTP2 响应 GOAWAY 这个帧)。您可以参考以下步骤开启 Sidecar 停止保障。
    1. 登录 服务网格控制台,单击需要变更配置的网格 ID,进入网格的管理页面。
    2. 在基本信息页面,单击 Sidecar 停止保障右侧的
    
    。如下图所示:
    
    
    以上是全局启用的方法,通常也建议全局启用,如果只想针对某些工作负载开启,也可以为 Pod 添加如下注解:
    proxy.istio.io/config: '{ "proxyMetadata": { "EXIT_ON_ZERO_ACTIVE_CONNECTIONS": "true" } }'
    
    
    

    自定义 sidecar 资源

    Sidecar 作为 Pod 中的一个 container,也需要设置 request 和 limit,如有需要,也可以自定义,您可以在网格基本信息页的高级设置中可以进行全局自定义。操作步骤如下:
    1. 登录 服务网格控制台,单击需要变更配置的网格 ID,进入网格的管理页面。
    2. 在基本信息页面,单击自定义 sidecar 资源右侧的
    
    。如下图所示:
    
    
    
    3. 在“自定义 sidecar 资源”弹窗中,编辑自定义资源。如下图所示:
    
    
    
    4. 单击保存
    如果希望对不同工作负载进行不同的自定义,也可以为 Pod 添加类似如下的注解:
    sidecar.istio.io/proxyCPU: "0.5"
    sidecar.istio.io/proxyCPULimit: '2'
    sidecar.istio.io/proxyMemory: "256Mi"
    sidecar.istio.io/proxyMemoryLimit: '2Gi'
    
    
    
    如果使用了 TKE Serverless,不希望因 Sidecar 的 request 和 limit 导致 Pod 规格变高很多,可以用注解只设置 request 不设置 limit,request 根据实际需要填写,填 “0” 就表示 Pod 规格完全不会因 Sidecar 而升配:
    sidecar.istio.io/proxyCPU: "0"
    sidecar.istio.io/proxyMemory: "0"
    
    联系我们

    联系我们,为您的业务提供专属服务。

    技术支持

    如果你想寻求进一步的帮助,通过工单与我们进行联络。我们提供7x24的工单服务。

    7x24 电话支持