<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>admission-webhook on </title>
    <link>/tags/admission-webhook/</link>
    <description>Recent content in admission-webhook on </description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Tue, 10 Nov 2026 00:15:00 +0800</lastBuildDate><atom:link href="/tags/admission-webhook/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Vault Agent Injector 的 admission webhook 机制</title>
      <link>/posts/vault-agent-injector-mutating-webhook/</link>
      <pubDate>Tue, 10 Nov 2026 00:15:00 +0800</pubDate>
      
      <guid>/posts/vault-agent-injector-mutating-webhook/</guid>
      <description>背景 一个非生产集群把 Vault Agent 的默认 CPU request 从 250m 调到 25m 之后（为什么要调见 K8s 应用从 Vault 取密钥：Agent sidecar、init-only、VSO、ESO 和 CSI 怎么选），已经在跑的 pod 仍然是 250m，要各自重启一次才变。同一个集群里的 vault-agent-injector 原来只有 1 个副本，后来改成 2 个副本并加了 PodDisruptionBudget，原因是它不可用的那段时间里新建的 pod 不会被注入 agent。
两件事来自同一个事实：injector 是一个 mutating admission webhook，在 pod 写进集群之前的准入阶段改写 pod 定义，本身用一个普通的 Deployment 部署。
集群里的 Deployment 和 MutatingWebhookConfiguration 这个集群里 injector 由两样东西组成，都是 Vault Helm chart 装的：
vault namespace 下的 Deployment vault-agent-injector，镜像 hashicorp/vault-k8s:1.4.2（2024-07-03 发布）。 一个 MutatingWebhookConfiguration vault-agent-injector-cfg，告诉 API server 创建 pod 时调用它。 为了看清每一步，用 kind 起了一个 Kubernetes 1.</description>
    </item>
    
  </channel>
</rss>
