脚本之家 服务器常用软件
快捷导航
您的位置：首页 → 网站技巧 → 服务器 → 云和虚拟化 → 云其它 → Istio 自动注入 sidecar 失败

Istio 自动注入 sidecar 失败导致无法访问webhook服务的解决方法

 更新时间：2023年10月26日 10:37:21   作者：张志翔的博客  
最近工作中在部署Istio环境的过程中发现官方示例启动的pod不能访问不到Istio的webhook,这个问题也是困扰了我一天,我把他归类到sidecar注入失败的情况下,本文给大家分享问题解决方法,感兴趣的朋友跟随小编一起看看吧

最近工作中在部署Istio环境的过程中发现官方示例启动的pod不能访问不到Istio的webhook，这个问题也是困扰了我一天，我把他归类到sidecar注入失败的情况下，特此记录，便于日后查阅。

1、第一种可能（我遇到的情况）

如果自动注入时，报如下错误信息：

Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "rev.validation.istio.io": failed to call webhook: Post "https://istiod.istio-system.svc:443/validate?timeout=10s": dial tcp 10.101.106.199:443: i/o timeout

造成上述问题的原因是 kube-apiserver 的 --enable-admission-plugins 没有配置 MutatingAdmissionWebhook,ValidatingAdmissionWebhook参数，所以解决问题的方法就是找到 kube-apiserver.yaml 配置文件，我是通过kubeadm安装的，所以路径在 /etc/kubernetes/manifests 下，把 --enable-admission-plugins 修改为 NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook 后保存文件，删掉 kube-apiserver 的pod，让他自己根据新的配置文件重新启动（注意：如果是用kubeadm安装的修改内容如果错误，可能会导致k8s集群中的kube-apiserver全部挂掉，导致无法访问集群，这时就需要从官网下载kube-apiserver二进制文件，重新拉起一个进程，再执行删除pod的操作），修改后文件内容如下：

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 192.168.1.61:6443
  creationTimestamp: null
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=192.168.1.61
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook
    - --enable-bootstrap-token-auth=true
    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
    - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
    - --etcd-servers=https://127.0.0.1:2379
    - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
    - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
    - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
    - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
    - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
    - --requestheader-allowed-names=front-proxy-client
    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
    - --requestheader-extra-headers-prefix=X-Remote-Extra-
    - --requestheader-group-headers=X-Remote-Group
    - --requestheader-username-headers=X-Remote-User
    - --secure-port=6443
    - --service-account-issuer=https://kubernetes.default.svc.cluster.local
    - --service-account-key-file=/etc/kubernetes/pki/sa.pub
    - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
    - --service-cluster-ip-range=10.96.0.0/12
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
    - --feature-gates=RemoveSelfLink=false
    image: registry.aliyuncs.com/google_containers/kube-apiserver:v1.23.0
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: 192.168.1.61
        path: /livez
        port: 6443
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    name: kube-apiserver
    readinessProbe:
      failureThreshold: 3
      httpGet:
        host: 192.168.1.61
        path: /readyz
        port: 6443
        scheme: HTTPS
      periodSeconds: 1
      timeoutSeconds: 15
    resources:
      requests:
        cpu: 250m
    startupProbe:
      failureThreshold: 24
      httpGet:
        host: 192.168.1.61
        path: /livez
        port: 6443
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    volumeMounts:
    - mountPath: /etc/ssl/certs
      name: ca-certs
      readOnly: true
    - mountPath: /etc/pki
      name: etc-pki
      readOnly: true
    - mountPath: /etc/kubernetes/pki
      name: k8s-certs
      readOnly: true
  hostNetwork: true
  priorityClassName: system-node-critical
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  volumes:
  - hostPath:
      path: /etc/ssl/certs
      type: DirectoryOrCreate
    name: ca-certs
  - hostPath:
      path: /etc/pki
      type: DirectoryOrCreate
    name: etc-pki
  - hostPath:
      path: /etc/kubernetes/pki
      type: DirectoryOrCreate
    name: k8s-certs
status: {}

2、第二种可能

安装 Istio 时，配置了 enableNamespacesByDefault: false

sidecarInjectorWebhook:
  enabled: true
  # 变量为true，就会为所有命名空间开启自动注入功能。如果赋值为false，则只有标签为istio-injection的命名空间才会开启自动注入功能
  enableNamespacesByDefault: false
  rewriteAppHTTPProbe: false

解决方法：

# 设置标签
$ kubectl label namespace default istio-injection=enabled --overwrite
# 查看
$ kubectl get namespace -L istio-injection
NAME                   STATUS   AGE    ISTIO-INJECTION
default                Active   374d   enabled

如果要重新禁用注入istio sidecar，执行下面命令：

$ kubectl label namespace default istio-injection=disabled --overwrite

3、第三种可能

安装 Istio 时，设置 autoInject: disabled

proxy:
  includeIPRanges: 192.168.16.0/20,192.168.32.0/20
  # 是否开启自动注入功能，取值enabled则该pods只要没有被注解为sidecar.istio.io/inject: "false",就会自动注入。如果取值为disabled，则需要为pod设置注解sidecar.istio.io/inject: "true"才会进行注入
  autoInject: disabled

解决方法：

  • 第一个方法：设置 autoInject: enabled
  • 第二个方法：在 Pod 或者 Deployment 声明 sidecar.istio.io/inject: "true"  

到此这篇关于Istio 自动注入 sidecar 失败导致无法访问webhook服务的文章就介绍到这了,更多相关Istio 自动注入 sidecar 失败内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:

相关文章

  • Rainbond配置组件自动构建部署官方文档讲解

    Rainbond配置组件自动构建部署官方文档讲解

    这篇文章主要为大家介绍了Rainbond配置组件自动构建部署官方文档讲解，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪
    2022-04-04
  • Kubernetes安全加固的一些实用建议

    Kubernetes安全加固的一些实用建议

    Kubernetes是一个自动化的容器编排平台,它负责应用的部署、应用的弹性以及应用的管理,这些都是基于容器的,下面这篇文章主要给大家介绍了关于Kubernetes安全加固的一些实用建议,需要的朋友可以参考下
    2022-02-02
  • kubernetes(k8s)中Yaml文件详解

    kubernetes(k8s)中Yaml文件详解

    这篇文章主要给大家介绍了关于kubernetes(k8s)中Yaml文件详解的相关资料,YAML是专门用来写配置文件的语言,非常简洁和强大,使用比json更方便,需要的朋友可以参考下
    2023-12-12
  • kubeadm 搭建 K8s的详细过程

    kubeadm 搭建 K8s的详细过程

    这篇文章主要介绍了kubeadm 搭建 K8s详细过程，环境使用 VirtualBox 构建的3台虚拟机，虚拟机网络配置的相关步骤给大家介绍的非常详细,需要的朋友可以参考下
    2022-04-04
  • Rainbond应用分享与发布官方文档说明

    Rainbond应用分享与发布官方文档说明

    这篇文章主要为大家介绍了Rainbond应用分享与发布的官方文档说明，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪
    2022-04-04
  • k8s实现身份认证策略及过程解析

    k8s实现身份认证策略及过程解析

    这篇文章主要为大家介绍了k8s实现身份认证策略及过程解析，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪
    2023-02-02
  • 普通人如何在区块链行业赚钱

    普通人如何在区块链行业赚钱

    区块链是一项新技术。之所以快速吸引人们的关注，是因为比特币在2017年的暴涨，迅速吸引了大众的视线。而比特币的底层技术，主要是区块链技术
    2018-03-03
  • 新版k8s拉取镜像失败问题解决办法

    新版k8s拉取镜像失败问题解决办法

    随着Kubernetes 1.23版本的发布,Docker作为默认容器运行时被弃用,转而默认采用Containerd,这一改变意味着用户在使用Kubernetes时,将不再通过Docker来拉取镜像,文中jiang,需要的朋友可以参考下
    2024-10-10
  • 解决k8s namespace 一直处于 Terminating 状态的问题

    解决k8s namespace 一直处于 Terminating 状态的问题

    这篇文章主要介绍了k8s namespace 一直处于 Terminating 状态的解决方法,以下的 tool 为 Terminating 状态的 namespace，下面相关的一些操作记得将 tool 修改成自己的 namespace 名称，需要的朋友可以参考下
    2022-10-10
  • 详解k8s NetworkPolicy 网络策略是怎么样的

    详解k8s NetworkPolicy 网络策略是怎么样的

    这篇文章主要为大家介绍了k8s NetworkPolicy 网络策略是怎么样的深入解析，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪
    2023-04-04

最新评论