云服务器内容精选

  • 规避方案 在Istio 1.7及以后版本,社区通过给istio-injector注入逻辑增加一个叫HoldApplicationUntilProxyStarts的开关来解决了该问题,开关打开后,Proxy将会注入到第一个Container,istio-proxy容器先于业务容器启动。 开关配置分为全局和局部两种,下面介绍两种启用方法。 需要注意的是,打开开关后,意味着业务容器需要等Sidecar完全Ready后才能启动,会让Pod启动速度变慢一些。在需要快速扩容应对突发流量场景可能会显得吃力,所以建议您自行评估业务场景,利用局部配置的方法,只给需要的业务打开此开关。 全局配置 执行以下命令,编辑IOP CR资源。 kubectl edit iop private-data-plane -n istio-system 在spec.values.global.proxy字段下添加以下配置: holdApplicationUntilProxyStarts: true 执行以下命令,确认最新日志无报错。 kubectl logs -n istio-operator $(kubectl get po -n istio-operator | awk '{print $1}' | grep -v NAME) 执行以下命令,确认IOP CR是正常状态。 kubectl get iop -n istio-system 执行以下命令,滚动升级已添加到网格的服务。 kubectl rollout restart deployment nginx -n default 其中,nginx为示例服务,default为命名空间,请替换为实际取值。 执行以下命令,确认Pod重启成功。 kubectl get pod -n default | grep nginx 执行以下命令,确认Pod正常添加了postStart lifecycle,并且istio-proxy容器放在了第一个位置。 kubectl edit pod nginx-7bc96f87b9-l4dbl 局部配置 如果使用Istio 1.8及其以上的版本,可以为需要打开此开关的Pod加上proxy.istio.io/config注解,将holdApplicationUntilProxyStarts置为true。 以default命名空间下nginx服务为例,用户其他服务操作类似。 kubectl edit deploy nginx -n default 在spec.template.metadata.annotations字段下添加以下配置: proxy.istio.io/config: | holdApplicationUntilProxyStarts: true
  • 如何为集群开放命名空间注入? 为集群的命名空间注入sidecar时,若集群未开放命名空间注入,请参考如下指导修改集群配置: 通过kubectl连接集群。 执行kubectl get iop -nistio-system,查询iop资源。 若回显如下,表示存在iop资源,请执行3。 若回显如下,表示不存在iop资源,请执行4。 执行kubectl edit iop -nistio-system data-plane,修改autoInject配置项。其中,data-plane为上一步查询的iop资源名称,请替换为实际值。 global: defaultPodDisruptionBudget: enabled: true hub: *.*.*.*:20202/asm logging: level: default:info meshID: test-payment multiCluster: clusterName: test-yy network: test-yy-network proxy: autoInject: enabled remotePilotAddress: *.*.*.* tag: 1.8.6-r1-20220512225026 执行kubectl edit cm -nistio-system istio-sidecar-injector,修改istio-sidecar-injector配置项。 data: config: |- policy: enabled 父主题: 网格管理
  • sidecar注入失败可能的原因 sidecar注入失败常见场景和解决方案: 可能原因:网格管理实例数到达上限,无法继续注入。 检查方法:统计网格注入Pod总数是否已达上限。 登录应用服务网格ASM控制台,在网格列表页面查看您的网格卡片展示的实例个数是否达到网格规格。如果达到即网格注入Pod总数已达上限。 解决方案:联系运维工程师或提交工单处理。 可能原因:控制面组件istiod异常。 检查方法:请检查istio-system命名空间下的istiod组件是否异常。 登录云容器引擎CCE控制台,依次单击您的集群名称-工作负载,选择istio-system命名空间,查看istiod-1-18-7-r4组件工作负载状态列是否是运行中,如果不是运行中则可能是组件异常了。 组件中的1-18-7-r4即网格的版本。网格版本号可从网格详情页面的“网格配置-基本信息”中获取,即“当前版本”的值。此处展示的版本号是中划线连接。 解决方案:若异常可以联系运维工程师或提交工单处理。 可能原因:命名空间未打上自动注入标签。 检查方法:执行以下命令,查看需要的webhook的 namespaceSelector条件。 kubectl get mutatingwebhookconfiguration istio-sidecar-injector-1-18-7-r4 -o yaml | grep "rev.namespace.sidecar-injector.istio.io" -A20 | grep "namespaceSelector:" -A7 请将上述命令中的1-18-7-r4按当前格式(中划线连接)替换成您的网格的版本。网格版本号可从网格详情页面的“网格配置-基本信息”中获取,即“当前版本”的值。 例如上图查询结果表示需要有一个istio.io/rev=1-18-7-r4的标签同时不能有istio-injection的标签。 执行以下命令,确认目标命名空间是否包含在 webhook范围内。 kubectl get {namespace} --show-labels 解决办法:命名空间添加上面查出来的注入标签。 可能原因:为集群开放命名空间注入的默认策略未设置为enable。 检查方法:执行以下命令检查默认策略,确认policy的值为enabled 。 kubectl -n istio-system get configmap istio-sidecar-injector-1-18-7-r4 -o jsonpath='{.data.config}' | grep policy: 请将上述命令中的1-18-7-r4按当前格式(中划线连接)替换成您的网格的版本。网格版本号可从网格详情页面获取,即“当前版本”的值。 解决办法:参考如何为集群开放命名空间注入?进行处理。 可能原因:存在sidecar.istio.io/inject: 'false'标签。 检查方法:检查工作负载标签。 登录云容器引擎CCE控制台,依次单击您的集群名称-工作负载,选择对应命名空间,单击您的工作负载操作列的“更多-查看YAML”。找到spec.template.metadata.labels字段,确认不能存在sidecar.istio.io/inject: 'false'标签。 请将上述命令中的1-18-7-r4按当前格式(中划线连接)替换成您的网格的版本。网格版本号可从网格详情页面获取,即“当前版本”的值。 解决办法:如果存在请删除sidecar.istio.io/inject: 'false'标签。参考某些工作负载不注入Sidecar,该如何配置? 可能原因:Pod不能创建。 解决方案:执行以下命令,查看events事件报错,根据events事件报错信息进一步处理。 kubectl describe -n {namespace} {deployment name} 可能原因:确保Pod 不在 kube-system 或 kube-public 命名空间中。 kube-system 以及 kube-public 命名空间中的 Pod 将忽略 Sidecar 自动注入。 可能原因:确保Pod 定义中没有 hostNetwork:true。 hostNetwork:true 的 Pod 将忽略 Sidecar 自动注入。 父主题: 网格管理
  • 解决方法 通过kubectl连接到CCE集群。 执行以下命令,清理istio相关资源。 kubectl delete ServiceAccount -n istio-system `kubectl get ServiceAccount -n istio-system | grep istio | awk '{print $1}'`kubectl delete ClusterRole -n istio-system `kubectl get ClusterRole -n istio-system | grep istio | awk '{print $1}'`kubectl delete ClusterRoleBinding -n istio-system `kubectl get ClusterRoleBinding -n istio-system | grep istio | awk '{print $1}'`kubectl delete job -n istio-system `kubectl get job -n istio-system | grep istio | awk '{print $1}'`kubectl delete crd -n istio-system `kubectl get crd -n istio-system | grep istio | awk '{print $1}'`kubectl delete mutatingwebhookconfigurations -n istio-system `kubectl get mutatingwebhookconfigurations -n istio-system | grep istio | awk '{print $1}'` 登录ASM控制台,重新执行卸载操作。
  • 企业版网格添加集群时,选择非扁平网络,为什么查询不到ELB? 企业版网格添加集群时,如果选择非扁平网络,ASM会为集群创建一个东西向流量网关,需要绑定一个私网负载均衡实例ELB,作为其他集群流量的入口。ASM会查询集群所处VPC下的所有私网ELB(如果ELB绑定了公网IP会被过滤),支持选择共享型和独享型ELB,其中独享型ELB必须包含网络型(TCP/UDP)规格。因此,如果查询不到ELB,可能原因是: 未购买ELB实例 所购买的ELB实例不在集群所处VPC下 ELB实例绑定了公网IP 独享型ELB未包含网络型(TCP/UDP)规格 当前Region暂不支持独享型ELB ASM支持独享型ELB目前仅在部分Region上线(如“华北-北京四”),其他Region会陆续上线,敬请关注。 关于非扁平网络的详细介绍请参见:非扁平网络。 父主题: 网格管理
  • 添加路由时,为什么选不到对应的服务? 添加路由时,目标服务会根据对应的网关协议进行过滤。过滤规则如下: HTTP协议的网关可以选择HTTP协议的服务 TCP协议的网关可以选择TCP协议的服务 GRPC协议的网关可以选择GRPC协议的服务 HTTPS协议的网关可以选择HTTP、GRPC协议的服务 TLS协议的网关如果打开了TLS终止,只能选择TCP协议的服务;关闭了TLS终止,只能选择TLS协议的服务 父主题: 添加服务
  • 原因分析 ASM服务网格对接至集群后,会在命名空间monitoring下创建一个otel-collector工作负载。创建这个工作负载的原因是需要利用其对envoy收集遥测数据(trace、log、metric),并进行处理,导出到相应的后端,实现网格的可观测性。 otel-collector架构简介 图1 otel-collector架构图 如上图的架构图所示,otel-collector包含了四个模块: Receivers 接收器Receivers是遥测数据进入otel-collector的方式,可以是推送或拉取。Receivers可以以多种格式接收遥测数据,例如上图中的OTLP、Jaeger、Prometheus格式。 Processors 处理器Processors用于处理Receivers收集到的数据,例如常用的batch处理器,用于对遥测数据进行批处理。 Exporters 导出器Exporters是将遥测数据发送到指定后端的方式,它帮助我们更好地可视化和分析遥测数据。 Extensions 扩展主要适用于不涉及处理遥测数据的任务。扩展是可选的,比如可以增加一个health_check的健康检查功能,获取有关Collector健康状况的信息。 otel-collector在ASM基础版网格中的使用 可通过以下命令获取otel-collector工作负载的配置信息: 以在基础版网格获取到的配置文件为例: receivers配置项定义了可以选择以zipkin、prometheus两种协议从envoy获取遥测数据,其中prometheus定义了以每15s的间隔从/stats/prometheus路径下抓取数据。 processors配置项定义了batch、memory_limiter两种对数据处理的方式,分别是批处理和内存限制。 exporters配置项定义了将处理过的遥测数据导出至apm服务器。 extensions配置项定义了health_check扩展,其用于获取有关otel-collector健康状况的信息。 service部分用于配置otel-collector实际会采用哪些上述定义好的配置项。 比如上述配置文件中service项,其配置了两个pipeline分别用于处理metrics数据和traces数据(注:一个pipeline是一组receivers, processors, 和exporters的集合),以及配置了logs输出级别为info及以上。其处理架构如下图所示。 图2 metrics、traces处理架构图
  • 负载级别配置拦截IP网段 通过配置业务deployment文件,可以在负载级别配置IP网段拦截: 执行kubectl edit deploy –n user_namespace user_deployment 1. 在deployment.spec.template.metadata.annotations中配置IP网段拦截traffic.sidecar.istio.io/includeOutboundIPRanges: 2. 在deployment.spec.template.metadata.annotations中配置IP网段不拦截traffic.sidecar.istio.io/excludeOutboundIPRanges: 注意:上述操作会导致业务容器滚动升级。
  • 金丝雀升级失败常见场景及解决方案 进行金丝雀升级时,升级失败的常见场景和解决方案: CRD检查失败。 解决办法:新版本Istio 将不支持部分CRD,包括:clusterrbacconfigs 、serviceroles 、servicerolebindings 、policies。若您在当前版本存在即将废弃的资源,则需要删除后再升级。 升级前检查网关配置信息时,Istio 网关标签错误。 解决办法:Istio 网关标签(matchLabels)必须为 {app: istio-ingressgateway, istio: ingressgateway}。 升级前插件检查失败。 解决办法:ASM从1.8版本开始不再支持如下插件(tracing,kiali,grafana,prometheus)部署,升级前需要将上述插件卸载。您可以自行安装开源版本插件,或者使用 APM 。 升级前集群状态检查任务失败。 解决办法:升级前会检查集群状态,若集群状态异常则无法进行网格升级。 升级前资源检查任务失败。 解决办法:金丝雀升级需要有充足资源。 升级前集群版本检查任务失败。 解决办法:网格支持的版本如下: 网格版本 支持的集群版本 1.3 1.13,1.15,1.17,1.19 1.6 1.15,1.17 1.8 1.15,1.17,1.19,1.21 1.13 1.21,1.23 1.15 1.21,1.23,1.25,1.27 1.18 1.25,1.27,1.28,1.29,1.30 升级前组件亲和性检查失败。 解决办法:若您从非金丝雀版本升级到金丝雀版本,需要满足打了istio:master labels的节点数量大于等于两倍的istiod实例数,并且所有可调度节点数大于等于ingressgateway/egressgateway 实例数量最大值的两倍,若不满足则需要将节点数量扩大到满足调度需求或者将istiod、ingressgateway、egressgateway pod反亲和性设置为尽量满足。 方法一:增加添加istio:master节点,可以从CCE console上进行操作。 方法二:修改pod反亲和策略,可在CCE界面修改yaml。 preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - istiod (如果是ingressgateway则为istio-egressgateway、istio-ingressgateway) namespaces: - istio-system topologyKey: kubernetes.io/hostname 或者在CCE界面升级设置工作负载反亲和性,改为尽量满足。 升级前命名空间自动注入检查失败。 解决办法:若您从专有网格迁移至基础网格,命名空间存在已经注入的pod,但是该命名空间未开启自动注入,则需要开启该命名空间自动注入。 父主题: 网格管理
  • 负载级别指定端口配置出入流量拦截 通过修改业务deployment文件,可以在负载级别配置端口上的出入流量拦截规则: 执行kubectl edit deploy –n user_namespace user_deployment 1. 在deployment.spec.template.metadata.annotations中配置入流量指定端口不拦截traffic.sidecar.istio.io/excludeInboundPorts: 2. 在deployment.spec.template.metadata.annotations中配置入流量指定端口拦截traffic.sidecar.istio.io/includeInboundPorts: 3. 在deployment.spec.template.metadata.annotations中配置出流量指定端口不拦截traffic.sidecar.istio.io/excludeOutboundPorts: 4. 在deployment.spec.template.metadata.annotations中配置出流量指定端口拦截traffic.sidecar.istio.io/includeOutboundPorts: 注意:上述操作完成后会导致业务容器滚动升级。
  • 问题背景 Istio CNI 插件可能会导致使用了 initContainer 的应用出现网络连通性问题。 使用 Istio CNI 时,kubelet 会通过以下步骤启动一个注入的 Pod: Istio CNI 插件在 Pod 内设置流量重定向到 Istio Sidecar。 等待所有的 Init 容器成功执行完毕。 Istio Sidecar 跟随 Pod 的其它容器一起启动。 由于 initContainer 在 Sidecar 启动之前执行,initContainer 发出的请求会被重定向到尚未启动的 Sidecar 上,这会导致 initContainer 执行期间出现流量丢失。
  • 解决方案 可以通过以下任意方式来防止流量丢失: 使用 runAsUser 将 Init 容器的 uid 设置为 1337。 1337 是 Sidecar 代理使用的 uid。 这个 uid 发送的流量并非通过 Istio 的 iptables 规则进行捕获。 应用容器流量仍将像往常一样被捕获。 对 initContainer 所访问的目标 CIDR,通过设置 traffic.sidecar.istio.io/excludeOutboundIPRanges 注解以使访问该网段的流量不会被重定向到 Sidecar。 对 initContainer 所访问的目标端口,通过设置 traffic.sidecar.istio.io/excludeOutboundPorts 注解以使访问该端口的流量不会被重定向到 Sidecar。 请谨慎使用注解方式排除流量拦截,因为 IP/端口排除注解不仅适用于 Init 容器流量,还适用于应用容器流量。 即发送到配置的 IP/端口的应用流量将绕过 Istio Sidecar。
  • 旧版ASM与新版ASM区别 对于同一个网格,建议不要在旧版ASM页面和新版ASM页面交替使用,因为会有一些数据兼容性问题。 旧版ASM与新版ASM的区别如下: Sidecar注入方式不同。旧版ASM创建的网格没有开启Sidecar的命名空间注入,新版ASM创建的网格开启了Sidecar的命名空间注入,命名空间注入详见:https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/。 Istio资源格式不同。旧版ASM创建的网格和新版ASM创建的网格管理的Istio资源(VirtualService和DestinationRule)格式不同。 灰度发布功能不兼容。例如:在新版ASM加入网格的服务不支持在旧版ASM进行灰度发布;在新版ASM创建的灰度发布任务无法在旧版ASM显示。 流量治理功能不兼容。例如:新版ASM配置的流量治理无法在旧版ASM页面显示或配置。
  • 操作场景 企业版网格可以管理多个集群(CCE集群和 CCE Turbo 集群均可),服务在跨集群通信时,如果网络访问不通,可能是因为未放通安全组规则导致的,需要按照本文指导配置安全组规则,有如下两种场景: CCE集群服务访问CCE集群服务,需要为集群的Node安全组入方向放通对方集群的容器网段。 CCE集群服务访问CCE Turbo集群服务,需要为Turbo集群的ENI安全组入方向放通CCE集群的容器网段。 CCE Turbo集群服务访问CCE集群服务,以及CCE Turbo集群服务之间互访,均无需额外配置安全组规则。 如果两个集群不在一个VPC内,需要先通过对等连接打通网络,具体操作请参见如何通过对等连接打通两个集群的VPC网络,实现实例跨集群通信?。
  • 集群校验报错常见场景及解决方案 为企业版网格添加集群时,系统会自动校验集群是否符合要求,集群校验报错常见场景及解决方案如下所述: 集群需要两个可用资源大于2 vCPUs、4GiB的节点,当前资源不足,无法创建网格 解决方案:在E CS 控制台选择对应的节点进行扩容。 集群容器网段与网格控制面网段冲突 解决方案: 已购买网格,添加集群场景:重新规划集群容器网段。 购买网格同时添加集群场景:修改网格控制面网段或重新规划集群容器网段。 集群容器网段与集群服务网段冲突 解决方案:重新规划集群容器网段,确保集群容器网段不与其他待添加集群的服务网段冲突,并且不与网格中已添加集群的服务网段冲突。 集群容器网段与集群VPC网段冲突(containerVPCNetworkOverlapping) 解决方案:重新规划集群容器网段,确保集群容器网段不与其他待添加集群的VPC网段冲突,并且不与网格中已添加集群的VPC网段冲突。 集群已存在istio-system命名空间 解决方案:删除已创建的istio-system命名空间。 集群所在VPC已经与其他服务网格建立对等连接 解决方案:请检查同一个VPC下的集群是否已添加到其他网格中,如果有,需要先移除同一个VPC下已添加到其他网格的所有集群。 集群和网格中已有集群网络类型冲突 解决方案:请检查待添加集群网络类型,如果是overlay_l2容器隧道网络类型,若网格中已存在集群,则会失败,需要先把网格中已添加集群全部移除;如果是VPC网络,若网格中已有overlay_l2容器隧道网络类型集群,则失败,需要把overlay_l2容器隧道网络类型集群移出网格。 集群服务网段与集群容器网段冲突 解决方案:重新规划集群服务网段,确保集群服务网段不与其他待添加集群的容器网段冲突,并且不与网格中已添加集群的容器网段冲突。 集群服务网段与网格控制面网段冲突 解决方案: 已购买网格,添加集群场景:重新规划集群服务网段。 购买网格同时添加集群场景:修改网格控制面网段或重新规划集群服务网段。 集群服务网段与集群服务网段冲突 解决方案:重新规划集群服务网段,确保集群服务网段不与其他待添加集群的服务网段冲突,并且不与网格中已添加集群的服务网段冲突。 集群服务网段与集群虚拟私有云网段冲突 解决方案:重新规划集群服务网段,确保集群服务网段不与其他待添加集群的VPC网段冲突,并且不与网格中已添加集群的VPC网段冲突。 集群虚拟私有云网段与集群容器网段冲突 解决方案:重新规划集群VPC网段,确保集群VPC网段不与其他集群的容器网段冲突。 集群虚拟私有云网段与网格控制面网段冲突 解决方案: 已购买网格,添加集群场景:重新规划集群VPC网段。 购买网格同时添加集群场景:修改网格控制面网段或重新规划集群VPC网段。 集群虚拟私有云网段与集群VPC网段冲突 解决方案:重新规划集群VPC网段,确保集群VPC网段不与其他集群的VPC网段冲突。 网格控制面网段与该集群VPC路由表中的路由(xx.xx.x.xxx)冲突,请检查同一个VPC的其他集群是否已添加到其他的网格 解决方案: 已购买网格,添加集群场景:待添加集群的VPC路由表中存在与网格控制面网段冲突的路由,确认是否可以删除该路由,不能删除路由则需要重新规划网格控制面网段购买网格。 购买网格同时添加集群场景:修改网格控制面网段。 集群虚拟私有云网段与集群服务网段冲突 解决方案:重新规划集群VPC网段,确保集群VPC网段不与其他集群的服务网段冲突。 父主题: 网格管理