阿里云Kubernetes容器服务Istio实践之Sidecar自动注入

简介: 本文重点介绍在阿里云Kubernetes容器服务中如何启用或者禁用Sidecar自动注入,并分析自动注入Sidecar的原理机制。使用该自动注入能力,可以简化部署应用的逻辑。同时,阿里云Kubernetes容器服务也提供了可配置选型,让用户可以根据自己的需要配置是否启用该能力。

概述

在前面系列文章中已经介绍了Istio及其各个核心组件,详述了如何利用阿里云Kubernetes容器服务,快速搭建一套用于连接、管理以及保护微服务的开放平台Istio,为应用引入和配置多个相关服务;并且通过一个官方示例演示了如何部署应用到上述Istio环境中,演示了如何设置智能路由、分布式追踪以及Istio 的遥测数据收集、查询及可视化等功能。

回顾这个系列文章请参考:
阿里云Kubernetes Service Mesh实践进行时(1): Istio初体验
阿里云Kubernetes Service Mesh实践进行时(2): 通过示例深入Istio
阿里云Kubernetes Service Mesh实践进行时(3): 智能路由
阿里云Kubernetes Service Mesh实践进行时(4): 分布式追踪
阿里云Kubernetes Service Mesh实践进行时(5): 遥测数据收集、查询及可视化
阿里云Kubernetes Service Mesh实践进行时(6): 故障诊断与检测工具Weave Scope
阿里云Kubernetes Service Mesh实践进行时(7): 可观测性分析服务Kiali

此外,阿里云Kubernetes容器服务已经提供了Istio与日志服务Log Service的集成能力,可以通过阿里云Kubernetes容器服务Istio实践之集成日志服务Log Service了解Istio与基于阿里云日志服务的分布式追踪系统的整合能力。

注意:在使用阿里云Kubernetes容器服务Istio 1.0的过程中,如果遇到类似CRD版本问题,请参考我们提供的问题分析。 我们会持续更新遇到的问题及其解决方法。

本文重点介绍在阿里云Kubernetes容器服务中如何启用或者禁用Sidecar自动注入,并分析自动注入Sidecar的原理机制。使用该自动注入能力,可以简化部署应用的逻辑。同时,阿里云Kubernetes容器服务也提供了可配置选型,让用户可以根据自己的需要配置是否启用该能力。

回顾Kubernetes Webhook机制

Admission是Kubernets中的一个术语,指的是Kubernets API Server资源请求过程中的一个阶段。如下图所示,在API Server接收到资源创建请求时,首先会对请求进行认证和鉴权,然后经过Admission处理,最后再保存到etcd。
图片.png

从图中看到,Admission中有两个重要的阶段:MutatingValidating,这两个阶段中执行的逻辑如下:

  • Mutating是从字面上可以知道在Mutating阶段可以对请求内容进行修改。
  • Validating是指在该阶段不允许修改请求内容,但可以根据请求的内容判断是继续执行该请求还是拒绝该请求。

Kubernets 1.9版本开始引入了Admission Webhook扩展机制,通过Webhook回调功能,开发者可以非常灵活地对Kubernets API Server的功能进行扩展,在API Server创建资源时对资源进行验证或者修改。

使用Webhook的优势是不需要对API Server的源码进行修改和重新编译就可以扩展其功能。插入的逻辑实现为一个独立的进程,通过参数方式传入到Kubernets中,由Kubernets在进行自身逻辑处理时对扩展逻辑进行回调。

通过Admission webhook,可以加入Mutation和Validation两种类型的webhook插件:

  • MutatingAdmissionWebhook允许你在Webhook中对资源对象进行mutate修改;
  • ValidatingAdmissionWebhook执行一些检查操作,可以拒绝用户的请求来增加额外的准入策略;

当集群管理员需要强制对某些请求或者所有请求都进行校验或者修改的时候,就可以考虑使用ValidatingAdmissionWebhook或MutatingAdmissionWebhook。

启用Webhook插件

在Kubernetes中,一些高级特性正常运行的前提条件是将相关的准入模块处于enable状态。对于Kubernetes APIServer来说,如果不恰当地配置了准入控制模块,它就不能正常工作或者某些功能也不会正常的生效。
在Kubernetes APIServer中有一个flag:--enable-admission-plugins,其值为一串用逗号连接起、有序的准入模块列表,设置后就可在对象操作前执行一定顺序的准入模块调用。

--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota

阿里云Kubernetes容器服务默认创建的集群(版本1.10.4) kube-apiserver中已经启用了插件MutatingAdmissionWebhook与ValidatingAdmissionWebhook。通过如下命令可以查看kube-apiserver对应的POD启用参数:

kubectl describe po -l component=kube-apiserver -n kube-system
Command:
      kube-apiserver
      --apiserver-count=500
      --runtime-config=admissionregistration.k8s.io/v1alpha1
      ......
      --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota
      ......

采用Webhook自动注入Istio Sidecar

Istio就是充分利用了Kubernets Webhook机制实现Envoy Proxy Sidecar的自动注入。

Sidecar注入配置项

首先,创建Sidecar注入的配置项istio-sidecar-injector,如下所示:

kubectl describe configmap istio-sidecar-injector -n istio-system
Name:         istio-sidecar-injector
Namespace:    istio-system
Labels:       app=ack-istio
              chart=ack-istio-1.0.0
              heritage=Tiller
              istio=sidecar-injector
              release=myistio
Annotations:  <none>

Data
====
config:
----
policy: enabled
template: |-
  initContainers:
  - name: istio-init
    image: "registry.cn-hangzhou.aliyuncs.com/aliacs-app-catalog/proxy_init:1.0.0"
    args:
    ......
    imagePullPolicy: IfNotPresent
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
      privileged: true
    restartPolicy: Always

  containers:
  - name: istio-proxy
    image: [[ if (isset .ObjectMeta.Annotations "sidecar.istio.io/proxyImage") -]]
    ......

可以看到该ConfigMap 保存了默认注入策略(policy)和 sidecar 注入模板(template)。
策略(policy)

  • disabled:sidecar 注入器默认不会注入到 pod 中。添加pod模板定义中的注解 sidecar.istio.io/inject 值为 true会启用注入功能。
  • enabled:sidecar 注入器默认会注入到 pod 中。添加pod模板定义中的注解 sidecar.istio.io/inject 值为 false会禁止注入功能。 ​

Sidecar注入Webhook

其次,部署Sidecar注入的Webhook,如下所示:

mutatingwebhook.yaml:

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
  name: istio-sidecar-injector
  namespace: {{ .Release.Namespace }}
  labels:
    app: istio-sidecar-injector
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
webhooks:
  - name: sidecar-injector.istio.io
    clientConfig:
      service:
        name: istio-sidecar-injector
        namespace: {{ .Release.Namespace }}
        path: "/inject"
      caBundle: ""
    rules:
      - operations: [ "CREATE" ]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
    failurePolicy: Fail
    namespaceSelector:
{{- if .Values.enableNamespacesByDefault }}
      matchExpressions:
      - key: istio-injection
        operator: NotIn
        values:
        - disabled
{{- else }}
      matchLabels:
        istio-injection: enabled
{{- end }}

注意的是,如果enableNamespacesByDefault设置为true时,会根据命名空间选择器的匹配规则来决定是否默认启用Sidecar自动注入,即istio-injection不为disabled;反之,如果enableNamespacesByDefault设置为false时,只有命令空间中设置了标签istio-injection并且值为enabled,才会启用Sidecar自动注入。

Sidecar注入的Deployment

可以查看部署好的istio-sidecar-injector容器:
图片.png
其对应的deployment.yaml如下:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: istio-sidecar-injector
  namespace: {{ .Release.Namespace }}
  labels:
    app: {{ template "sidecar-injector.name" . }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
    istio: sidecar-injector
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    metadata:
      labels:
        istio: sidecar-injector
    spec:
      serviceAccountName: istio-sidecar-injector-service-account
      containers:
        - name: sidecar-injector-webhook
          image: "{{ .Values.global.hub }}/{{ .Values.image }}:{{ .Values.global.tag }}"
          imagePullPolicy: {{ .Values.global.imagePullPolicy }}
          args:
            - --caCertFile=/etc/istio/certs/root-cert.pem
            - --tlsCertFile=/etc/istio/certs/cert-chain.pem
            - --tlsKeyFile=/etc/istio/certs/key.pem
            - --injectConfig=/etc/istio/inject/config
            - --meshConfig=/etc/istio/config/mesh
            - --healthCheckInterval=2s
            - --healthCheckFile=/health

开启需要自动注入Sidecar的命令空间

根据上述的启用Sidecar自动注入规则,enableNamespacesByDefault设置为false时,命令空间中设置了标签istio-injection并且值为enabled,才会启用Sidecar自动注入。
执行以下命令可以为命令空间default增加标签istio-injection且值设为enabled。

kubectl label namespace default istio-injection=enabled

至此,命令空间default已经支持Sidecar自动注入,运行如下命令等同于前面文章中介绍的手工注入,系统会自动注入Envoy容器作为Sidecar。

kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml

总结

本文重点介绍在阿里云Kubernetes容器服务中如何启用或者禁用Sidecar自动注入,并分析自动注入Sidecar的原理机制。使用该自动注入能力,可以简化部署应用的逻辑。同时,阿里云Kubernetes容器服务也提供了可配置选型,让用户可以根据自己的需要配置是否启用该能力。

欢迎大家使用阿里云上的容器服务,快速搭建微服务的开放治理平台Istio,比较简单地集成到自己项目的微服务开发中。

相关实践学习
使用ACS算力快速搭建生成式会话应用
阿里云容器计算服务 ACS(Container Compute Service)以Kubernetes为使用界面,采用Serverless形态提供弹性的算力资源,使您轻松高效运行容器应用。本文将指导您如何通过ACS控制台及ACS集群证书在ACS集群中快速部署并公开一个容器化生成式AI会话应用,并监控应用的运行情况。
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
9月前
|
Kubernetes Docker Python
Docker 与 Kubernetes 容器化部署核心技术及企业级应用实践全方案解析
本文详解Docker与Kubernetes容器化技术,涵盖概念原理、环境搭建、镜像构建、应用部署及监控扩展,助你掌握企业级容器化方案,提升应用开发与运维效率。
1223 108
|
8月前
|
Kubernetes Devops Docker
Kubernetes 和 Docker Swarm:现代 DevOps 的理想容器编排工具
本指南深入解析 Kubernetes 与 Docker Swarm 两大主流容器编排工具,涵盖安装、架构、网络、监控等核心维度,助您根据团队能力与业务需求精准选型,把握云原生时代的技术主动权。
723 115
|
8月前
|
存储 Kubernetes 网络安全
关于阿里云 Kubernetes 容器服务(ACK)添加镜像仓库的快速说明
本文介绍了在中国大陆地区因网络限制无法正常拉取 Docker 镜像的解决方案。作者所在的阿里云 Kubernetes 集群使用的是较旧版本的 containerd(1.2x),且无法直接通过 SSH 修改节点配置,因此采用了一种无需更改 Kubernetes 配置文件的方法。通过为 `docker.io` 添加 containerd 的镜像源,并使用脚本自动修改 containerd 配置文件中的路径错误(将错误的 `cert.d` 改为 `certs.d`),最终实现了通过多个镜像站点拉取镜像。作者还提供了一个可重复运行的脚本,用于动态配置镜像源。虽然该方案能缓解镜像拉取问题,
850 3
|
存储 负载均衡 测试技术
ACK Gateway with Inference Extension:优化多机分布式大模型推理服务实践
本文介绍了如何利用阿里云容器服务ACK推出的ACK Gateway with Inference Extension组件,在Kubernetes环境中为多机分布式部署的LLM推理服务提供智能路由和负载均衡能力。文章以部署和优化QwQ-32B模型为例,详细展示了从环境准备到性能测试的完整实践过程。
|
存储 人工智能 Kubernetes
ACK Gateway with AI Extension:面向Kubernetes大模型推理的智能路由实践
本文介绍了如何利用阿里云容器服务ACK推出的ACK Gateway with AI Extension组件,在Kubernetes环境中为大语言模型(LLM)推理服务提供智能路由和负载均衡能力。文章以部署和优化QwQ-32B模型为例,详细展示了从环境准备到性能测试的完整实践过程。
|
存储 人工智能 物联网
ACK Gateway with AI Extension:大模型推理的模型灰度实践
本文介绍了如何使用 ACK Gateway with AI Extension 组件在云原生环境中实现大语言模型(LLM)推理服务的灰度发布和流量分发。该组件专为 LLM 推理场景设计,支持四层/七层流量路由,并提供基于模型服务器负载感知的智能负载均衡能力。通过自定义资源(CRD),如 InferencePool 和 InferenceModel,可以灵活配置推理服务的流量策略,包括模型灰度发布和流量镜像。
|
存储 监控 对象存储
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
421 0
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
|
存储 监控 对象存储
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
324 1

相关产品

  • 容器计算服务
  • 容器服务Kubernetes版
  • 推荐镜像

    更多