Kubernetes学习笔记 – Kubernetes学习笔记

Source: 概述

Wed, 14 May 2025 00:00:00 +0000

api 信息

api 列表

admission
admissionregistration
apidiscovery
apiserverinternal
apps
authentication
authorization
autoscaling
batch
certificates
coordination
core
discovery
doc.go
events
extensions
flowcontrol
imagepolicy
networking
node
policy
rbac
resource
scheduling
storage
storagemigration

API 版本

大部分 api 都有多个版本，如：

v1
v1alpha1
v1beta1

代码学习中，我们以 v1 版本为主。

api 代码结构

基本上每个 api 文件夹都有如下的文件列表：

doc.go
generated.pb.go
register.go
types.go
types_swagger_doc_generated.go
zz_generated.deepcopy.go
zz_generated.prerelease-lifecycle.go

doc.go

这是包的文档文件，包含包的用途说明和基本的文档注释

通常会包含 +k8s:openapi-gen=true 这样的代码生成标记

定义了包的帮助文档和代码生成器的元数据。

打开看源码，发现除了 license 之外，只定义了 package 名字和该 package 相关的注解，如：

// +k8s:deepcopy-gen=package
// +k8s:protobuf-gen=package
// +k8s:openapi-gen=false
// +k8s:prerelease-lifecycle-gen=true
// +groupName=admission.k8s.io

package v1

generated.pb.go

generated.pb.go 是 Protocol Buffers 的生成文件（由 generated.proto 生成），包含了 AdmissionReview 等类型的 Protocol Buffers 序列化相关代码，用于 Kubernetes API 的 gRPC 通信和存储序列化。

代码都是从 generated.proto 文件生成的，没啥好看的，直接看 generated.proto 文件好了。

generated.proto

generated.proto 是Protocol Buffers 的定义文件，定义了当前 API 类型的 protobuf 消息格式。

generated.proto 文件会被 protoc 编译器用来生成 generated.pb.go

register.go

types.go

最重要的文件，包含核心 API 类型的 Go 定义，定义了 API 相关的各种结构体，包含字段定义、标签注释和验证逻辑，有详细的字段注释说明每个字段的用途

types_swagger_doc_generated.go

自动生成的 Swagger 文档，包含 API 类型的详细文档，用于生成 Kubernetes API 参考文档。

这些注释会被 Kubernetes API 文档工具使用。

zz_generated.deepcopy.go

自动生成的 DeepCopy 方法实现，包含 api 类型的深拷贝方法，由 deepcopy-gen 工具根据 types.go 中的标记生成。

Kubernetes 运行时需要这些方法来安全地复制对象。

zz_generated.prerelease-lifecycle.go

自动生成的 API 生命周期相关代码，包含 API 版本的弃用和移除策略，由 prerelease-lifecycle-gen 工具生成。

用于管理 API 版本的生命周期（alpha/beta/stable 状态转换）。

Concepts: pod

Mon, 01 Feb 2021 00:00:00 +0000

https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

Pod（就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）容器；这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的 “逻辑主机”，其中包含一个或多个应用容器，这些容器相对紧密地耦合在一起。在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。

除了应用容器，Pod 还可以包含在 Pod 启动期间运行的 Init 容器。你也可以在集群支持临时性容器的情况下，为调试的目的注入临时性容器。

什么是 Pod？

Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离方面，即用来隔离容器的技术。在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。

Pod 类似于共享名字空间并共享文件系统卷的一组容器。

使用 Pod

Pod 通常不是直接创建的，而是使用工作负载资源创建的。

Pod 怎样管理多个容器

Pod 被设计成支持形成内聚服务单元的多个协作过程（形式为容器）。 Pod 中的容器被自动安排到集群中的同一物理机或虚拟机上，并可以一起进行调度。容器之间可以共享资源和依赖、彼此通信、协调何时以及何种方式终止自身。

Pod 天生地为其成员容器提供了两种共享资源：网络和存储。

资源共享和通信

Pod 使它的成员容器间能够进行数据共享和通信。

Pod 中的存储

Pod 可以设置一组共享的存储卷。 Pod 中的所有容器都可以访问该共享卷，从而允许这些容器共享数据。

Pod 联网

每个 Pod 都在每个地址族中获得一个唯一的 IP 地址。 Pod 中的每个容器共享网络名字空间，包括 IP 地址和网络端口。 Pod 内的容器可以使用 localhost 互相通信。当 Pod 中的容器与 Pod 之外的实体通信时，它们必须协调如何使用共享的网络资源（例如端口）。

在同一个 Pod 内，所有容器共享一个 IP 地址和端口空间，并且可以通过 localhost 发现对方。他们也能通过如 SystemV 信号量或 POSIX 共享内存这类标准的进程间通信方式互相通信。

Concepts: 概述

Mon, 01 Feb 2021 00:00:00 +0000

https://kubernetes.io/zh-cn/docs/concepts/overview/

https://kubernetes.io/docs/concepts/overview/

Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。K8s 这个缩写是因为 K 和 s 之间有 8 个字符的关系。

Google 在 2014 年开源了 Kubernetes 项目。 Kubernetes 建立在 Google 大规模运行生产工作负载十几年经验的基础上，结合了社区中最优秀的想法和实践。

为什么需要 Kubernetes，它能做什么？

Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移你的应用、提供部署模式等。

Kubernetes 为你提供：

服务发现和负载均衡
存储编排
自动部署和回滚
自动完成装箱计算
自我修复
密钥与配置管理
批处理执行
水平扩缩
IPv4/IPv6 双栈
为可扩展性设计

Kubernetes 不是什么

Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统

Kubernetes：

不限制支持的应用程序类型。
不部署源代码，也不构建你的应用程序。
不提供应用程序级别的服务作为内置服务
不是日志记录、监视或警报的解决方案。
不提供也不要求配置用的语言、系统（例如 jsonnet）
不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。
此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。

Docs: Sidecar Container概述

Mon, 01 Feb 2021 00:00:00 +0000

From Kubernetes 1.18 containers can be marked as sidecars

Unfortunately, that features has been removed from 1.18, then removed from 1.19 and currently has no specific date for landing.

reference: kubernetes/enhancements#753

资料

官方正式资料

k8s pod概念
Sidecar Containers（kubernetes/enhancements#753）: 最权威的资料了，准备细读
Support startup dependencies between containers on the same Pod

社区介绍资料

Sidecar Containers improvement in Kubernetes 1.18: 重点阅读
Kubernetes — Learn Sidecar Container Pattern
Sidecar container lifecycle changes in Kubernetes 1.18
Tutorial: Apply the Sidecar Pattern to Deploy Redis in Kubernetes
Sidecar Containers：by 陈鹏，特别鸣谢

Docs: KEP753: Sidecar Container

Tue, 23 Feb 2021 00:00:00 +0000

Docs: 推翻KEP753的讨论

Tue, 23 Feb 2021 00:00:00 +0000

https://github.com/kubernetes/enhancements/pull/1980

这是一个关于 sidecar 的讨论汇总，最后得出的结论是推翻 kep753.

起于derekwaynecarr的发言

I want to capture my latest thoughts on sidecar concepts, and get a path forward.

Here is my latest thinking:

我想归纳我对 sidecar 概念的最新思考，并得到一条前进的道路。

这是我的最新思考。

I think it’s important to ask if the introduction of sidecar containers will actually address an end-user requirement or just shift a problem and further constrain adoption of sidecars themselves by pod authors. To help frame this exercise, I will look at the proposed use of sidecar containers in the service mesh community.

我认为重要的是要问一下 sidecar容器的引入是否会真正解决最终用户的需求，或者只是转移一个问题，并进一步限制pod作者对sidecars本身的采用。为了帮助构架这项工作，我将看看服务网格社区中拟议的 sidecar 容器的使用情况。

User story

I want to enable mTLS for all traffic in my mesh because my auditor demands it.

我想在我的Mesh中启用mTLS，因为我的会计要求这样做。

The proposed solution is the introduction of sidecar containers that change the pod lifecycle:

提出的解决方案是引入sidecar container，改变 pod 的生命周期:

Init containers start/stop
Sidecar containers start
Primary containers start/stop
Sidecar containers stop

The issue with the proposed solution meeting the user story is as follows:

建议的解决方案可以满足用户故事的问题如下：

Init containers are not subject to service mesh because the proxy is not running. This is because init containers run to completion before starting the next container. Many users do network interaction that should be subject to the mesh in their init container.

Init container 不受服务网格的影响，因为代理没有运行。这是因为init container 在启动下一个容器之前会运行到完成状态。很多用户在 init container 中做网络交互，应该受制于网格。
Sidecar containers (once introduced) will be used by users for use cases unrelated to the mesh, but subject to the mesh. The proposal makes no semantic guarantees on ordering among sidecars. Similar to init containers, this means sidecars are not guaranteed to participate in the mesh.

Sidecar 容器(一旦引入)将被用户用于与网格无关但受网格制约的用例。该提案没有对sidecars之间的顺序进行语义保证。与 init 容器类似，这意味着 sidecar 不能保证参与 mesh。

The real requirement is that the proxy container MUST stop last even among sidecars if those sidecars require network.

真正的需求是，如果这些sidecar需要网络，代理容器也必须最后停止，即使代理容器也是 sidecar。

Similar to the behavior observed with init containers (users externalize run-once setup from their main application container), the introduction of sidecar containers will result in more elements of the application getting externalized into sidecars, but those elements will still desire to be part of the mesh when they require a network. Hence, we are just shifting, and not solving the problem.

与观察到的init容器的行为类似（用户从他们的主应用容器中外部化一次性设置），引入sidecar容器将导致更多的应用元素被外部化到sidecar中，但是当这些元素需要网络时，它们仍然会渴望成为网格结构的一部分。因此，我们只是在转移，而不是解决问题。

Given the above gaps, I feel we are not actually solving a primary requirement that would drive improved adoption of a service mesh (ensure all traffic is mTLS from my pod) to meet auditing.

鉴于上述差距，我觉得我们并没有实际上解决主要需求，这个需求将推动服务网格的改进采用（确保所有来自我的pod的流量都是mTLS），以满足审计。

Alternative proposal:

Support an ordered graph among containers in the pod (it’s inevitable), possibly with N rings of runlevels?
Identify which containers in that graph must run to completion before initiating termination (Job use case).
Move init containers into the graph (collapse the concept)
Have some way to express if a network is required by the container to act as a hint for the mesh community on where to inject a proxy in the graph.

替代建议:

支持在pod中的容器之间建立一个有序图(这是不可避免的)，可能有N个运行级别的环？

识别该图中的哪些容器必须在启动终止之前运行至完成状态（Job用例）。

将 init 容器移入图中（折叠概念）。

有某种方式来标记容器是否需要网络，用来作为网格社区的提示，在图中某处注入代理。

A few other notes based on Red Hat’s experience with service mesh:

Red Hat does not support injection of privileged sidecar containers and will always require CNI approach. In this flow, the CNI runs, multus runs, iptables are setup, and then init containers start. The iptables rules are setup, but no proxy is running, so init containers lose connectivity. Users are unhappy that init containers are not participating in the mesh. Users should not have to sacrifice usage of an init container (or any aspect of the pod lifecycle) to fulfill auditor requirements. The API should be flexible enough to support graceful introduction in the right level of a intra pod life-cycle graph transparent to the user.

根据红帽在服务网格方面的经验，还有一些其他说明：

红帽不支持注入特权sidecar容器，总是需要CNI方式。在这个流程中，CNI运行，multus运行，设置iptables，然后 init 容器启动。iptables规则设置好了，但是没有代理运行，所以 init容器失去了连接。用户对init容器不参与网格感到不满。用户不应该为了满足审计师的要求而牺牲init容器的使用（或pod生命周期的任何方面）。API应该足够灵活，以支持在正确的层次上优雅地引入对用户透明的 pod 生命周期图。

Proposed next steps:

Get a dedicated set of working meetings to ensure that across the mesh and kubernetes community, we can meet a users auditing requirement without limiting usage or adoption of init containers and/or sidecar containers themselves by pod authors.
I will send a doodle.

拟议的下一步措施：

召开一组专门的工作会议，以确保在整个mesh和kubernetes社区，我们可以满足用户审计要求，而不限制pod作者使用或采用init容器和/或sidecar容器本身。

我会发一个涂鸦。

其他人的意见

mrunalp：

Agree! We might as well tackle this general problem vs. doing it step by step with baggage added along the way.

同意! 我们不妨解决这个普遍性的问题，而不是按部就班地做，在做的过程中增加包袱。

sjenning ：

I agree @derekwaynecarr

I think that in order to satisfy fully the use cases mentioned, we are gravitating toward systemd level semantics where there is just an ordered graph of ~~services~~ containers in the pod spec.

You could basically collapse init containers into the normal containers map and add two fields to Container; oneshot bool that expresses if the container terminates and dependent containers should wait for it to terminate (handles init containers w/ ordering), and requires map[string] a list of container names upon which the current container depends.

This is flexible enough to accommodate a oneshot: true container (init container) depending on a oneshot: false container (a proxy container on which the init container depends).

Admittedly this would be quite the undertaking and there is API compatibility to consider.

我同意 @derekwaynecarr

我认为，为了充分满足上述用例，我们正在倾向于systemd级别的语义，在pod规范中，需要有一个有序的服务容器图。

你基本上可以把init容器折叠到普通容器图中，并在Container中添加两个字段； oneshot bool，表示容器是否终止，依赖的容器是否应该等待它终止（处理init容器 w/排序），和 requires map[string] 一个当前容器依赖的容器名称列表。

这足够灵活，可以容纳一个 oneshot: true 容器（init 容器）依赖于一个 oneshot: false 容器（init 容器依赖的代理容器）。

诚然，这将是一个相当大的工程，而且还要考虑API的兼容性。

thockin：

I have also been thinking about this. There are a number of open issues, feature-requests, etc that all circle around the topic of pod and container lifecycle. I’ve been a vocal opponent of complex API here, but it’s clear that what we have is inadequate.

When we consider init-container x sidecar-container, it is clear we will inevitably eventually need an init-sidecar.

我也一直在思考这个问题。有一些开放的问题、功能需求等，都是围绕着pod和容器生命周期这个话题展开的。我在这里一直是复杂API的强烈反对者，但很明显，我们所拥有的是不够的。

当我们考虑 init-container x sidecar-container 时，很明显我们最终将不可避免地需要一个init-sidecar。

Some (non-exhaustive) of the other related topics:

Node shutdown -> Pod shutdown (in progress?)
Voluntary pod restart (“Something bad happened, please burn me down to the ground and start over”)
Voluntary pod failure (“I know something you don’t, and I can’t run here - please terminate me and do not retry”)
“Critical” or “Keystone” containers (“when this container exits, the rest should be stopped”)
Startup/shutdown phases with well-defined semantics (e.g. “phase 0 has no network”)
Mixed restart policies in a pod (e.g. helper container which runs and terminates)
Clearer interaction between pod, network, and device plugins

其他的一些（非详尽的）相关主题：

节点关闭 -> Pod关闭（正在进行中？

自愿重启pod（“发生了不好的事情，请把我摧毁，然后重新开始”）。

自愿pod失败(“我知道一些你不知道的事情，我无法在这里运行–请终止我，不要重试”)

“关键 “或 “基石 “容器（“当这个容器退出时，其他容器应停止”）。

具有明确语义的启动/关闭阶段（如 “phase 0 没有网络”）。

在一个pod中混合重启策略（例如，帮助容器，它会运行并终止）。

更清晰的 pod、网络和设备插件之间的交互。

** thockin：**

This is a big enough topic that we almost certainly need to explore multiple avenues before we can have confidence in any one.

这是一个足够大的话题，我们几乎肯定需要探索多种途径，才能对任何一种途径有信心。

kfox1111:

the dependency idea also would allow for doing an init container, then a sidecar network plugin, then more init containers, etc, which has some nice features.

Also the readyness checks and oneshot could all play together with the dependencies so the next steps aren’t started before ready.

So, as a user experience, I think that api might be very nice.

Implementation wise there are probably lots of edge cases to carefully consider there.

依赖的想法还可以做一个init容器，然后做一个sidecar网络插件，然后做更多的init容器等等，这有一些不错的功能。

另外 readyness 检查和 oneshot 都可以和依赖一起考虑，这样就不会在准备好之前就开始下一步。

所以，作为用户体验来说，我觉得这个api可能是非常不错的。

从实现上来说，可能有很多边缘情况需要仔细考虑。

SergeyKanzhelev:

this is great idea to set up a working group to move it forward in bigger scope. One topic I suggest we cover early on in the discussions is whether we need to address the existing pain point of injecting sidecars in jobs in 1.20. This KEP intentionally limited the scope to just this - formalizing what people are already trying to do today with workarounds.

From Google side we also would love the bigger scope of a problem be addressed, but hope to address some immediate pain points early if possible. Either in current scope or slightly bigger.

这是一个很好的想法，成立一个工作组，在更大范围内推进它。我建议我们在讨论中尽早涉及的一个话题是，我们是否需要在1.20中解决现有的Job中注入 sidecar 的痛点。这个KEP有意将范围限制在这一点上–将人们今天已经在尝试的工作方法正式化。

从Google方面来说，我们也希望更大范围的问题能够得到解决，但如果可能的话，希望能够尽早解决一些直接的痛点。要么在目前的范围内，要么稍微大一点。

derekwaynecarr：

I would speculate that the dominant consumer of the job scenario is a job that required participation in a mesh to complete its task, and since I don’t see much point in solving for the mesh use case (which I view as the primary motivator for defining side car semantics) for only one workload type, I would rather ensure a pattern that solves the problem in light of our common experience across mesh and k8s communities.

我推测工作场景的主要消费者是需要参与网格来完成任务的Job，由于我认为只为一种工作负载类型解决mesh用例（我认为这是定义 sidecar 语义的主要动机）没有太大意义，所以我宁愿根据我们在 mesh 和k8s社区中的共同经验，确保一个能解决问题的模式。

Docs: 准备工作

Thu, 13 Nov 2025 00:00:00 +0000

系统更新

确保更新debian系统到最新，移除不再需要的软件，清理无用的安装包：

sudo apt update && sudo apt full-upgrade -y
sudo apt autoremove
sudo apt autoclean

如果更新了内核，最好重启一下。

swap 分区

安装 Kubernetes 要求机器不能有 swap 分区。

参考：

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#swap-configuration

开启模块

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

# Apply sysctl params without reboot
sudo sysctl --system

container runtime

Kubernetes 支持多种 container runtime，这里暂时继续使用 docker engine + cri-dockerd。

参考：

https://kubernetes.io/docs/setup/production-environment/container-runtimes/

安装 docker

docker 的安装参考：

https://skyao.net/learning-docker/docs/installation/debian13/

最方便的方式就是使用离线安装包进行安装。

安装 containerd

TODO：后面考虑换 containerd

安装 helm

参考：

https://helm.sh/docs/intro/install/#from-apt-debianubuntu

选择用官方脚本安装 Helm（以便绕过无法访问的 apt 仓库）:

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

输出为：

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 11929  100 11929    0     0  48738      0 --:--:-- --:--:-- --:--:-- 48889
Downloading https://get.helm.sh/helm-v3.20.2-linux-amd64.tar.gz
Verifying checksum... Done.
Preparing to install helm into /usr/local/bin
helm installed into /usr/local/bin/helm

验证版本：

helm version

版本显示为 v3.20.2：

version.BuildInfo{Version:"v3.20.2", GitCommit:"8fb76d6ab555577e98e23b7500009537a471feee", GitTreeState:"clean", GoVersion:"go1.25.9"}

Source: 概述

Wed, 14 May 2025 00:00:00 +0000

介绍

Admission API 主要用于动态准入控制（Dynamic Admission Control），即在 Kubernetes API 请求被处理之前或之后，对其进行拦截、验证或修改。它的主要功能包括：

验证（Validation）：检查资源的合法性（如 Pod 的镜像是否符合安全策略）。
变更（Mutation）：修改请求的内容（如自动注入 Sidecar 容器）。
审计（Auditing）：记录 API 请求的详细信息，用于安全审计。

Admission API 通常与 Admission Webhooks 配合使用，允许用户自定义准入逻辑（如通过 Webhook 调用外部服务）。

核心类型

Admission API 主要定义在 types.go 中，核心结构体包括：

AdmissionReview
- 用于封装 准入请求（Request） 和 准入响应（Response）。
- 是 Webhook 和 API Server 之间的通信格式。
AdmissionRequest

表示一个 准入请求，包含所有需要验证或修改的资源信息。
AdmissionResponse

表示 准入控制的结果，决定是否允许该请求，并可以返回修改内容。

HTTP 方法

Admission API 本身不直接提供 REST API，而是 由 API Server 调用 Webhook 时使用。其交互流程如下：

API Server 收到请求（如 kubectl create -f pod.yaml）。
API Server 构造 AdmissionReview，发送给配置的 Webhook。
Webhook 处理请求，返回 AdmissionReview{ Response: ... }。
API Server 根据响应决定是否继续处理。

使用场景

Admission API 通常用于：

强制安全策略（如禁止特权容器）。
资源默认值注入（如自动设置 requests/limits）。
Sidecar 注入（如 Istio 自动注入 istio-proxy）。
自定义验证逻辑（如检查 Ingress 域名是否合法）。

Source: 概述

Wed, 14 May 2025 00:00:00 +0000

介绍

AdmissionRegistration API 核心功能：用于注册和管理 Kubernetes 的动态准入控制 Webhook，允许用户在不修改 API Server 代码的情况下扩展准入控制逻辑。

主要分为两类：

MutatingAdmissionWebhook
- 用于修改 API 请求对象（如自动注入 Sidecar 容器）
ValidatingAdmissionWebhook
- 用于验证 API 请求对象（如检查资源是否符合安全策略）

核心类型

在 admissionregistration.k8s.io/v1 中定义了以下关键资源：

MutatingWebhookConfiguration
- 用于注册多个 修改型 Webhook。
- 每个 Webhook 指定：
  - 触发规则（匹配哪些 API 请求）
  - 调用的 Webhook 服务地址
  - 失败策略（如拒绝请求或忽略错误）
ValidatingWebhookConfiguration
- 用于注册多个 验证型 Webhook。
- 结构与 MutatingWebhookConfiguration 类似，但 Webhook 不能修改对象。

核心 API 方法

AdmissionRegistration API 通过标准的 Kubernetes REST 接口提供以下操作：

HTTP 方法	路径	功能
`GET`	`/apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations`	列出所有 MutatingWebhookConfiguration
`POST`	同上	创建新的 MutatingWebhookConfiguration
`PUT`	`/apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/{name}`	更新指定配置
`DELETE`	同上	删除配置
`GET`	`/apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations`	列出所有 ValidatingWebhookConfiguration
`POST`	同上	创建新的 ValidatingWebhookConfiguration

关键字段解析

(1) `WebhookClientConfig`

type WebhookClientConfig struct {
    URL      *string           `json:"url,omitempty"`      // Webhook 服务 URL（直接调用）
    Service  *ServiceReference `json:"service,omitempty"`  // 通过 Service 调用
    CABundle []byte            `json:"caBundle,omitempty"`  // CA 证书（用于 TLS 验证）
}

支持两种调用方式：
- 直接指定 URL（如 https://webhook.example.com:443/admit）
- 通过 Kubernetes Service 调用（推荐）

(2) RuleWithOperations

type RuleWithOperations struct {
    Operations []OperationType `json:"operations"`  // 操作类型：CREATE, UPDATE, DELETE, *
    Rule       Rule            `json:"rule"`        // 资源匹配规则
}

示例：匹配所有 Pod 的 CREATE/UPDATE 操作：

rules:
- operations: ["CREATE", "UPDATE"]
  apiGroups: [""]
  apiVersions: ["v1"]
  resources: ["pods"]

(3) FailurePolicy

type FailurePolicyType string
const (
    Ignore FailurePolicyType = "Ignore"  // 失败时忽略（继续请求）
    Fail   FailurePolicyType = "Fail"    // 失败时拒绝请求
)

工作原理

API Server 接收请求（如创建 Pod）
检查匹配的 Webhook 规则
- 通过 rules 字段过滤
调用 Webhook 服务
- 发送 AdmissionReview 请求
处理响应
- 根据 allowed 和 patch 字段决定是否允许请求

Source: 概述

Wed, 14 May 2025 00:00:00 +0000

介绍

APIDiscovery API 的核心功能是提供 Kubernetes API 的动态发现机制，使客户端能够自动发现集群支持的 API 资源及其详细信息。

主要解决以下问题：

API 资源发现：客户端无需硬编码即可知道集群支持哪些 API（如 pods、deployments 等）
版本兼容性：发现不同 API 版本（如 v1、v1beta1）及其差异
API 聚合支持：支持自定义 API Server（Aggregated API Server）的自动注册和发现
高效缓存：客户端可以缓存发现信息，减少不必要的 API 调用

核心 API 资源类型

在 apidiscovery.k8s.io/v2（最新版本）中定义了以下关键结构：

(1) APIGroupDiscovery

// 描述一个 API 组的所有可用版本和资源
type APIGroupDiscovery struct {
    metav1.TypeMeta `json:",inline"`
    metav1.GroupVersion `json:",inline"`  // 例如 "apps/v1"
    Versions []APIVersionDiscovery `json:"versions"`  // 该组下的所有版本
}

(2) APIVersionDiscovery

// 描述一个 API 版本下的所有资源
type APIVersionDiscovery struct {
    Version string `json:"version"`  // 例如 "v1"
    Resources []APIResourceDiscovery `json:"resources"`  // 该版本下的资源列表
    Freshness metav1.ConditionStatus `json:"freshness"`  // 表示数据是否最新
}

(3) APIResourceDiscovery

// 描述单个 API 资源的详细信息
type APIResourceDiscovery struct {
    Resource string `json:"resource"`  // 例如 "pods"
    ResponseKind *metav1.GroupVersionKind `json:"responseKind"`  // 返回的 Kind
    Scope ScopeType `json:"scope"`  // 作用域（Namespaced/Cluster）
    SingularResource string `json:"singularResource"`  // 单数形式（如 "pod"）
    Verbs []string `json:"verbs"`  // 支持的动词（get/list/watch 等）
    ShortNames []string `json:"shortNames"`  // 缩写（如 "po"）
    Categories []string `json:"categories"`  // 所属分类（如 "all"）
    Subresources []APISubresourceDiscovery `json:"subresources"`  // 子资源
}

核心 API 方法

APIDiscovery API 通过以下标准 HTTP 端点提供服务：

HTTP 方法	路径	功能
`GET`	`/apis/apidiscovery.k8s.io/v2`	获取 APIDiscovery API 自身的描述
`GET`	`/apis/apidiscovery.k8s.io/v2/apigroups`	获取所有 API 组的发现信息
`GET`	`/apis/apidiscovery.k8s.io/v2/apigroups/{group}`	获取特定 API 组的发现信息

工作原理

客户端首次查询

kubectl get --raw /apis/apidiscovery.k8s.io/v2beta1/apigroups

解析响应
- 获取所有 API 组、版本、资源及其能力
建立本地缓存
- 客户端缓存发现结果，后续只检查 Freshness
处理 API 变更
- 当 API 扩展（如 CRD 注册）时，APIServer 自动更新发现信息

实际应用场景

(1) kubectl 自动补全

# kubectl 依赖发现 API 实现自动补全
kubectl get <TAB>  # 显示所有可用资源类型

(2) 客户端库初始化

// client-go 使用发现 API 初始化动态客户端
discoveryClient := clientset.Discovery()
resources, err := discoveryClient.ServerResources()

(3) 自定义控制器开发

// 动态发现新的 CRD
discoveryClient.Discovery().ServerPreferredResources()

源码学习路径

类型定义： staging/src/k8s.io/api/apidiscovery/v2/types.go
服务端实现： pkg/controlplane/apiserver/discovery/
客户端缓存逻辑： staging/src/k8s.io/client-go/discovery/

Source: 概述

Wed, 14 May 2025 00:00:00 +0000

介绍

apiserverinternal API 的核心功能是提供 API Server 的内部状态管理和协调机制，主要服务于以下场景：

存储版本管理
- 跟踪资源对象在 etcd 中的存储版本（Storage Version）
- 确保多版本 API 的兼容性转换
API Server 实例协调
- 在多个 API Server 实例间同步状态信息
- 支持高可用部署模式下的协调
内部状态监控
- 暴露 API Server 的内部健康状态和性能指标

核心 API 资源类型

在 apiserverinternal.k8s.io/v1alpha1 中定义了以下关键资源：

StorageVersion
StorageVersionStatus
ServerStorageVersion

关键工作流程

(1) 存储版本协商

当资源存在多版本（如 v1 和 v1beta1）时：
- 所有 API Server 实例通过 StorageVersion 资源协商出一个统一的存储版本
- 写入 etcd 时统一转换为该版本
客户端请求时按需转换回目标版本

(2) 状态同步示例

# 示例：Deployment 资源的存储版本状态
apiVersion: apiserverinternal.k8s.io/v1alpha1
kind: StorageVersion
metadata:
  name: deployments.apps
status:
  storageVersions:
  - apiServerID: "kube-apiserver-xyz"
    encodingVersion: "apps/v1"
    decodableVersions: ["apps/v1", "apps/v1beta1"]
  commonEncodingVersion: "apps/v1"

实际应用场景

(1) 版本升级监控

# 查看当前存储版本协商状态
kubectl get storageversions.apiserverinternal.k8s.io

(2) 多版本兼容性保障

确保旧版本客户端（如使用 apps/v1beta1）仍能读写数据
API Server 自动处理版本转换

(3) API Server 运维

检测集群中不同 API Server 实例的版本一致性
灰度升级时监控版本迁移状态

源码学习路径

类型定义： staging/src/k8s.io/api/apiserverinternal/v1alpha1/types.go
控制器逻辑： pkg/controlplane/storageversiongc/ （存储版本垃圾回收） pkg/apiserver/storageversion/ （版本协调主逻辑）
客户端交互： staging/src/k8s.io/client-go/applyconfigurations/apiserverinternal/

调试技巧

# 查看所有资源的存储版本
kubectl get storageversions.apiserverinternal.k8s.io -o yaml

# 检查特定资源（如 Deployment）
kubectl get storageversions deployments.apps -o yaml

设计意义

解耦存储与 API 版本：允许 etcd 存储格式独立于对外暴露的 API 版本
平滑升级：支持多版本共存期间的无缝转换
分布式协调：解决多 API Server 实例的状态一致性问题

Source: 概述

Wed, 14 May 2025 00:00:00 +0000

介绍

apps API 的核心功能是提供对应用层工作负载的声明式管理，主要包括：

部署管理：滚动更新、回滚、扩缩容
状态维护：确保应用实例数与声明的一致
版本控制：管理应用更新时的版本切换
与底层资源（Pod）的协调

主要管理的资源类型：

无状态应用（Deployment）
有状态应用（StatefulSet）
守护进程（DaemonSet）
一次性任务（ReplicaSet，通常由 Deployment 自动管理）

核心 API 资源类型

在 apps/v1 中定义了以下关键资源（所有资源均为 namespace-scoped）：

Deployment
DaemonSet
StatefulSet
ReplicaSet

源码学习路径

类型定义：

staging/src/k8s.io/api/apps/v1/types.go

控制器实现：

Deployment: pkg/controller/deployment/
StatefulSet: pkg/controller/statefulset/
DaemonSet: pkg/controller/daemon/

客户端操作：

staging/src/k8s.io/client-go/kubernetes/typed/apps/v1/

设计意义

抽象与自动化：将 Pod 管理从手动操作转为声明式管理
版本化运维：支持灰度发布、金丝雀发布等高级部署模式
状态分离：区分应用定义（Spec）和运行时状态（Status）

Source: 概述

Wed, 14 May 2025 00:00:00 +0000

介绍

authentication API 的核心功能是处理 Kubernetes 集群的身份认证，确保请求来源的合法性。

主要职责包括：

验证请求者身份：
- 确认用户、ServiceAccount 或外部系统的身份凭证
支持多种认证机制：
- X.509 客户端证书
- Bearer Token（如 ServiceAccount Token）
- 身份代理（OIDC、LDAP 等）
提供认证配置管理：
- 管理 TLS 证书配置
- 管理 ServiceAccount 的 Token 签发

核心 API 资源类型

在 authentication.k8s.io/v1 和核心 API 组中定义了以下关键资源：

(1) TokenReview

// 用于验证 Bearer Token 的有效性
type TokenReview struct {
    metav1.TypeMeta `json:",inline"`
    Spec   TokenReviewSpec   `json:"spec"`
    Status TokenReviewStatus `json:"status,omitempty"`
}

关键字段：

spec.token：待验证的 Token 字符串
status.authenticated：验证结果（true/false）
status.user：认证通过后的用户信息（用户名、组等）

(2) CertificateSigningRequest (CSR)

// 在 certificates.k8s.io/v1 中定义，但用于认证流程
type CertificateSigningRequest struct {
    metav1.TypeMeta `json:",inline"`
    Spec   CertificateSigningRequestSpec `json:"spec"`
}

关键字段：

spec.request：PEM 编码的证书签名请求
spec.signerName：指定签名用途（如 kubernetes.io/kube-apiserver-client）

(3) ServiceAccount

// 在核心 v1 API 中定义，用于 Pod 身份认证
type ServiceAccount struct {
    metav1.TypeMeta `json:",inline"`
    Secrets []ObjectReference `json:"secrets,omitempty"` // 关联的 Token Secret
}

Source: 概述

Wed, 14 May 2025 00:00:00 +0000

介绍

authorization API 的核心功能:决定是否允许某个主体（用户/ServiceAccount/组）执行特定操作。

Source: 组件

Wed, 14 May 2025 00:00:00 +0000

有哪些组件？

如何得知 k8s 有哪些组件？

看 k8s 进程

在 k8s 的 master 上，用 ps 命令查看 k8s 相关的进程：

ps -ef | grep -v kworker | grep -v nfs | grep -v nginx | grep -v pause | grep -v containerd | grep -v smbd | grep -v cpuhd | grep -v sshd  | grep -v /usr/bin | grep -v /usr/sbin | grep -v scsi | grep -v /sbin

排除和k8s无关的进程，能看到：

root        1388    1299  0 May13 ?        00:04:25 kube-scheduler --authentication-kubeconfig=/etc/kubernetes/scheduler.conf --authorization-kubeconfig=/etc/kubernetes/scheduler.conf --bind-address=127.0.0.1 --kubeconfig=/etc/kubernetes/scheduler.conf --leader-elect=true
root        1398    1297  0 May13 ?        00:17:47 kube-apiserver --advertise-address=192.168.3.112 --allow-privileged=true --authorization-mode=Node,RBAC --client-ca-file=/etc/kubernetes/pki/ca.crt --enable-admission-plugins=NodeRestriction --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
root        1399    1295  0 May13 ?        00:08:55 etcd --advertise-client-urls=https://192.168.3.112:2379 --cert-file=/etc/kubernetes/pki/etcd/server.crt --client-cert-auth=true --data-dir=/var/lib/etcd --experimental-initial-corrupt-check=true --experimental-watch-progress-notify-interval=5s --initial-advertise-peer-urls=https://192.168.3.112:2380 --initial-cluster=k8s112=https://192.168.3.112:2380 --key-file=/etc/kubernetes/pki/etcd/server.key --listen-client-urls=https://127.0.0.1:2379,https://192.168.3.112:2379 --listen-metrics-urls=http://127.0.0.1:2381 --listen-peer-urls=https://192.168.3.112:2380 --name=k8s112 --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt --peer-client-cert-auth=true --peer-key-file=/etc/kubernetes/pki/etcd/peer.key --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt --snapshot-count=10000 --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
root        1401    1293  0 May13 ?        00:05:33 kube-controller-manager --allocate-node-cidrs=true --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf --bind-address=127.0.0.1 --client-ca-file=/etc/kubernetes/pki/ca.crt --cluster-cidr=10.244.0.0/16 --cluster-name=kubernetes --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt --cluster-signing-key-file=/etc/kubernetes/pki/ca.key --controllers=*,bootstrapsigner,tokencleaner --kubeconfig=/etc/kubernetes/controller-manager.conf --leader-elect=true --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --root-ca-file=/etc/kubernetes/pki/ca.crt --service-account-private-key-file=/etc/kubernetes/pki/sa.key --service-cluster-ip-range=10.96.0.0/12 --use-service-account-credentials=true
root        3114    2988  0 May13 ?        00:00:07 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=k8s112
root        5283    5118  0 May13 ?        00:00:39 /opt/bin/flanneld --ip-masq --kube-subnet-mgr
1001        8052    7828  0 May13 ?        00:00:06 /dashboard-auth
65532       8054    7829  0 May13 ?        00:00:51 /coredns -conf /etc/coredns/Corefile
1001        8069    7948  0 May13 ?        00:00:06 /dashboard-api --insecure-bind-address=0.0.0.0 --bind-address=0.0.0.0 --namespace=kubernetes-dashboard --metrics-scraper-service-name=kubernetes-dashboard-metrics-scraper
1001        8070    7940  0 May13 ?        00:00:05 /dashboard-metrics-scraper
sky         8072    7968  0 May13 ?        00:01:29 /metrics-server --cert-dir=/tmp --secure-port=10250 --kubelet-preferred-address-types=InternalIP --kubelet-insecure-tls --kubelet-use-node-status-port --metric-resolution=15s
1001        8073    7860  0 May13 ?        00:00:05 /dashboard-web --insecure-bind-address=0.0.0.0 --bind-address=0.0.0.0 --namespace=kubernetes-dashboard --settings-config-map-name=kubernetes-dashboard-web-settings
65532       8083    7937  0 May13 ?        00:00:53 /coredns -conf /etc/coredns/Corefile

这里面直接和k8s相关的进程有：

coredns
etcd
kube-controller-manager
kube-proxy
kube-apiserver
kube-scheduler

k8s 扩展之一的 dashboard:

dashboard-api
dashboard-metrics-scraper
dashboard-web
dashboard-auth

k8s 扩展之一的 metrics-server:

metrics-server

看 k8s build 的产物

clone k8s 的源码：

https://github.com/kubernetes/kubernetes/

然后 build 一下：

git clone https://github.com/kubernetes/kubernetes
cd kubernetes
make

可以看到构建的日志：

+++ [0514 21:34:35] Building go targets for linux/amd64
    github.com/onsi/ginkgo/v2/ginkgo (non-static)
    k8s.io/apiextensions-apiserver (static)
    k8s.io/component-base/logs/kube-log-runner (static)
    k8s.io/kube-aggregator (static)
    k8s.io/kubernetes/cluster/gce/gci/mounter (static)
    k8s.io/kubernetes/cmd/kubeadm (static)
    k8s.io/kubernetes/cmd/kube-apiserver (static)
    k8s.io/kubernetes/cmd/kube-controller-manager (static)
    k8s.io/kubernetes/cmd/kubectl (static)
    k8s.io/kubernetes/cmd/kubectl-convert (static)
    k8s.io/kubernetes/cmd/kubelet (non-static)
    k8s.io/kubernetes/cmd/kubemark (static)
    k8s.io/kubernetes/cmd/kube-proxy (static)
    k8s.io/kubernetes/cmd/kube-scheduler (static)
    k8s.io/kubernetes/test/conformance/image/go-runner (non-static)
    k8s.io/kubernetes/test/e2e/e2e.test (test)
    k8s.io/kubernetes/test/e2e_node/e2e_node.test (test)

构建的产物在 _output/bin 目录下，可以看到：

$ pwd
/home/sky/work/code/kubernetes/kubernetes/_output/bin

$ ls -la
total 1069404
drwxrwxr-x 2 sky sky      4096 May 14 21:34 .
drwxrwxr-x 3 sky sky      4096 May 14 20:50 ..
-rwxr-xr-x 1 sky sky  75759800 May 14 21:34 apiextensions-apiserver
-rwxr-xr-x 1 sky sky 117823416 May 14 21:34 e2e_node.test
-rwxr-xr-x 1 sky sky 126209360 May 14 21:34 e2e.test
-rwxr-xr-x 1 sky sky  10580260 May 14 21:34 ginkgo
-rwxr-xr-x 1 sky sky   2056484 May 14 21:34 go-runner
-rwxr-xr-x 1 sky sky  74133688 May 14 21:34 kubeadm
-rwxr-xr-x 1 sky sky  73158840 May 14 21:34 kube-aggregator
-rwxr-xr-x 1 sky sky  98341048 May 14 21:34 kube-apiserver
-rwxr-xr-x 1 sky sky  91111608 May 14 21:34 kube-controller-manager
-rwxr-xr-x 1 sky sky  59900088 May 14 21:34 kubectl
-rwxr-xr-x 1 sky sky  58917048 May 14 21:34 kubectl-convert
-rwxr-xr-x 1 sky sky  82080036 May 14 21:34 kubelet
-rwxr-xr-x 1 sky sky   1839288 May 14 21:34 kube-log-runner
-rwxr-xr-x 1 sky sky  80322744 May 14 21:34 kubemark
-rwxr-xr-x 1 sky sky  70992056 May 14 21:34 kube-proxy
-rwxr-xr-x 1 sky sky  70004920 May 14 21:34 kube-scheduler
-rwxr-xr-x 1 sky sky   1757368 May 14 21:34 mounter

可以看到，k8s 的组件有：

apiextensions-apiserver
kubeadm
kube-aggregator
kube-apiserver
kube-controller-manager
kubectl
kubectl-convert
kubelet
kube-log-runner
kubemark
kube-proxy
kube-scheduler

Concepts: Kubernetes 对象概述

Mon, 31 Mar 2025 00:00:00 +0000

理解 Kubernetes 对象

在 Kubernetes 系统中，Kubernetes 对象是持久化的实体。

Kubernetes 对象是一种“意向表达（Record of Intent）”。一旦创建该对象， Kubernetes 系统将不断工作以确保该对象存在。通过创建对象，你本质上是在告知 Kubernetes 系统，你想要的集群工作负载状态看起来应是什么样子的，这就是 Kubernetes 集群所谓的期望状态（Desired State）。

笔记：k8s 中处处都在体现申明式 API。

对象规约（Spec）与状态（Status）

spec 描述希望对象所具有的特征： 期望状态（Desired State）。

status 描述对象的当前状态（Current State）

必需字段

要创建的 Kubernetes 对象需要配置的字段如下：

apiVersion - 创建该对象所使用的 Kubernetes API 的版本
kind - 想要创建的对象的类别
metadata - 唯一标识对象的数据，包括 name 字符串、UID 和可选的 namespace
spec - 期望的对象的状态

Concepts: Kubernetes 组件

Mon, 31 Mar 2025 00:00:00 +0000

https://kubernetes.io/zh-cn/docs/concepts/overview/components/

https://kubernetes.io/docs/concepts/overview/components/

笔记

Concepts: 服务网络概述

Wed, 05 Mar 2025 00:00:00 +0000

https://kubernetes.io/zh-cn/docs/concepts/services-networking/

Kubernetes 网络模型

Kubernetes 强制要求所有网络设施都满足以下基本要求（从而排除了有意隔离网络的策略）：

Pod 能够与所有其他节点上的 Pod 通信，且不需要网络地址转译（NAT）
节点上的代理（比如：系统守护进程、kubelet）可以和节点上的所有 Pod 通信

Kubernetes 的 IP 地址存在于 Pod 范围内 —— 容器共享它们的网络命名空间 —— 包括它们的 IP 地址和 MAC 地址。

Kubernetes 网络解决四方面的问题：

Pod 中的容器之间通过本地回路（loopback）通信。
集群网络在不同 Pod 之间提供通信。
Service API 允许向外暴露 Pod 中运行的应用，以支持来自于集群外部的访问。
- Ingress 提供专门用于暴露 HTTP 应用程序、网站和 API 的额外功能。
你也可以使用 Service 来发布仅供集群内部使用的服务。

Concepts: 官方文档

Wed, 05 Mar 2025 00:00:00 +0000

中文： https://kubernetes.io/zh-cn/docs/concepts/workloads/
英文： https://kubernetes.io/docs/concepts/workloads/

工作负载是在 Kubernetes 上运行的应用程序。

在 Kubernetes 中，无论你的负载是由单个组件还是由多个一同工作的组件构成，你都可以在一组 Pod 中运行它。在 Kubernetes 中，Pod 代表的是集群上处于运行状态的一组容器的集合。

Kubernetes Pod 遵循预定义的生命周期。例如，当在你的集群中运行了某个 Pod，但是 Pod 所在的节点出现致命错误时，所有该节点上的 Pod 的状态都会变成失败。Kubernetes 将这类失败视为最终状态：即使该节点后来恢复正常运行，你也需要创建新的 Pod 以恢复应用。

不过，为了减轻用户的使用负担，通常不需要用户直接管理每个 Pod。而是使用负载资源来替用户管理一组 Pod。这些负载资源通过配置控制器来确保正确类型的、处于运行状态的 Pod 个数是正确的，与用户所指定的状态相一致。

Kubernetes 提供若干种内置的工作负载资源：

Deployment 和 ReplicaSet （替换原来的资源 ReplicationController）。 Deployment 很适合用来管理你的集群上的无状态应用，Deployment 中的所有 Pod 都是相互等价的，并且在需要的时候被替换。
StatefulSet 让你能够运行一个或者多个以某种方式跟踪应用状态的 Pod。例如，如果你的负载会将数据作持久存储，你可以运行一个 StatefulSet，将每个 Pod 与某个 PersistentVolume 对应起来。你在 StatefulSet 中各个 Pod 内运行的代码可以将数据复制到同一 StatefulSet 中的其它 Pod 中以提高整体的服务可靠性。
DaemonSet 定义提供节点本地支撑设施的 Pod。这些 Pod 可能对于你的集群的运维是非常重要的，例如作为网络链接的辅助工具或者作为网络插件的一部分等等。每次你向集群中添加一个新节点时，如果该节点与某 DaemonSet 的规约匹配，则控制平面会为该 DaemonSet 调度一个 Pod 到该新节点上运行。
Job 和 CronJob。定义一些一直运行到结束并停止的任务。你可以使用 Job 来定义只需要执行一次并且执行后即视为完成的任务。你可以使用 CronJob 来根据某个排期表来多次运行同一个 Job。

在庞大的 Kubernetes 生态系统中，你还可以找到一些提供额外操作的第三方工作负载相关的资源。通过使用定制资源定义（CRD），你可以添加第三方工作负载资源，以完成原本不是 Kubernetes 核心功能的工作。例如，如果你希望运行一组 Pod，但要求所有 Pod 都可用时才执行操作（比如针对某种高吞吐量的分布式任务），你可以基于定制资源实现一个能够满足这一需求的扩展，并将其安装到集群中运行。

Client: Kubernetes 平台一览

Mon, 01 Feb 2021 00:00:00 +0000

在链条的一侧，用户声明高级资源来构建要部署的应用程序： Deployments，Ingresses，等等。

在中间，controller 被激活，将这些资源转化为低级别的资源（Pod），调度器将这些资源分配到节点。在链条的另一端，节点代理将低级别的资源部署到节点上。

Kubernetes 平台的主要元素（通常称为控制平面）在图1-1中突出显示，并在下文中描述：

API server: 这是控制平面上的中心点；用户和控制平面的各个部分联系这个API来创建、获取、删除、更新和观察资源。
etcd数据库: 只能由API服务器访问，用于保存与资源有关的数据。
Controller manager: 运行 Controller，将用户声明的高级资源转化为部署在节点上的低级别资源。控制器连接到API服务器，观察高层资源，创建、删除和更新低层资源，以满足高层资源中声明的规格。
Scheduler: 将低级资源分配到各个节点上。调度器连接到API服务器，观察未受影响的资源并将其连接到节点上。
Kubelet: 这是一个运行在集群所有节点上的代理，每个代理都管理着影响到其节点的工作负载。kubelet 连接到 API 服务器，观察影响到其节点的Pods资源，并使用本地容器运行时部署相关容器。
Kube proxy: 这是一个在集群的所有节点上运行的代理，每个代理都管理着影响其节点的网络配置。Kube proxy 连接到API服务器，观察服务资源并在其节点上配置相关的网络规则。

Concepts: Pod 的生命周期

Mon, 01 Feb 2021 00:00:00 +0000

https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/

本页面讲述 Pod 的生命周期。 Pod 遵循预定义的生命周期，起始于 Pending 阶段，如果至少其中有一个主要容器正常启动，则进入 Running，之后取决于 Pod 中是否有容器以失败状态结束而进入 Succeeded 或者 Failed 阶段。

在 Kubernetes API 中，Pod 包含规约部分和实际状态部分。 Pod 对象的状态包含了一组 Pod 状况（Conditions）。如果应用需要的话，你也可以向其中注入自定义的就绪态信息。

Pod 在其生命周期中只会被调度一次。一旦 Pod 被调度（分派）到某个节点，Pod 会一直在该节点运行，直到 Pod 停止或者被终止。

Pod 生命期

Pod 也被认为是相对临时性（而不是长期存在）的实体。

Pod 会被创建、赋予一个唯一的 ID（UID），并被调度到节点，并在终止（根据重启策略）或删除之前一直运行在该节点。

Pod 阶段

Pod 的阶段（Phase）是 Pod 在其生命周期中所处位置的简单宏观概述。该阶段并不是对容器或 Pod 状态的综合汇总，也不是为了成为完整的状态机。

Pod 阶段的数量和含义是严格定义的。

除了本文档中列举的内容外，不应该再假定 Pod 有其他的 phase 值。

取值	描述
`Pending`（悬决）	Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间。
`Running`（运行中）	Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。
`Succeeded`（成功）	Pod 中的所有容器都已成功终止，并且不会再重启。
`Failed`（失败）	Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。
`Unknown`（未知）	因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。

说明： 当一个 Pod 被删除时，执行一些 kubectl 命令会展示这个 Pod 的状态为 Terminating（终止）。这个 Terminating 状态并不是 Pod 阶段之一。 Pod 被赋予一个可以体面终止的期限，默认为 30 秒。

笔记： Terminating 不是 pod 阶段之一。

容器状态

容器的状态有三种：Waiting（等待）、Running（运行中）和 Terminated（已终止）。

`Waiting` （等待）

如果容器并不处在 Running 或 Terminated 状态之一，它就处在 Waiting 状态。处于 Waiting 状态的容器仍在运行它完成启动所需要的操作：例如，从某个容器镜像仓库拉取容器镜像，或者向容器应用 Secret 数据等等。当你使用 kubectl 来查询包含 Waiting 状态的容器的 Pod 时，你也会看到一个 Reason 字段，其中给出了容器处于等待状态的原因。

`Running`（运行中）

Running 状态表明容器正在执行状态并且没有问题发生。如果配置了 postStart 回调，那么该回调已经执行且已完成。如果你使用 kubectl 来查询包含 Running 状态的容器的 Pod 时，你也会看到关于容器进入 Running 状态的信息。

`Terminated`（已终止）

处于 Terminated 状态的容器已经开始执行并且或者正常结束或者因为某些原因失败。如果你使用 kubectl 来查询包含 Terminated 状态的容器的 Pod 时，你会看到容器进入此状态的原因、退出代码以及容器执行期间的起止时间。

如果容器配置了 preStop 回调，则该回调会在容器进入 Terminated 状态之前执行。

容器重启策略

Pod 的 spec 中包含一个 restartPolicy 字段，其可能取值包括 Always、OnFailure 和 Never。默认值是 Always。

restartPolicy 适用于 Pod 中的所有容器。restartPolicy 仅针对同一节点上 kubelet 的容器重启动作。当 Pod 中的容器退出时，kubelet 会按指数回退方式计算重启的延迟（10s、20s、40s、…），其最长延迟为 5 分钟。一旦某容器执行了 10 分钟并且没有出现问题，kubelet 对该容器的重启回退计时器执行重置操作。

Pod 状况

Pod 有一个 PodStatus 对象

Kubelet 管理以下 PodCondition：

PodScheduled：Pod 已经被调度到某节点；
PodHasNetwork：Pod 沙箱被成功创建并且配置了网络（Alpha 特性，必须被显式启用）；
ContainersReady：Pod 中所有容器都已就绪；
Initialized：所有的 Init 容器都已成功完成；
Ready：Pod 可以为请求提供服务，并且应该被添加到对应服务的负载均衡池中。

字段名称	描述
`type`	Pod 状况的名称
`status`	表明该状况是否适用，可能的取值有 “`True`"、"`False`” 或 “`Unknown`”
`lastProbeTime`	上次探测 Pod 状况时的时间戳
`lastTransitionTime`	Pod 上次从一种状态转换到另一种状态时的时间戳
`reason`	机器可读的、驼峰编码（UpperCamelCase）的文字，表述上次状况变化的原因
`message`	人类可读的消息，给出上次状态转换的详细信息

Pod 网络就绪

特性状态： Kubernetes v1.25 [alpha]

在 Pod 被调度到某节点后，它需要被 Kubelet 接受并且挂载所需的卷。一旦这些阶段完成，Kubelet 将与容器运行时（使用容器运行时接口（Container Runtime Interface；CRI））一起为 Pod 生成运行时沙箱并配置网络。如果启用了 PodHasNetworkCondition 特性门控， kubelet 会通过 Pod 的 status.conditions 字段中的 PodHasNetwork 状况来报告 Pod 是否达到了初始化里程碑。

Concepts: Service

Mon, 01 Feb 2021 00:00:00 +0000

https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/

Service 是将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。

动机

Pod 是非永久性资源
每个 Pod 都有自己的 IP 地址
在 Deployment 中，在同一时刻运行的 Pod 集合可能与稍后运行该应用程序的 Pod 集合不同。

Service 资源

Kubernetes Service 定义了这样一种抽象：逻辑上的一组 Pod 和一种可以访问它们的策略

定义 Service

定义 service 需要最基本的两个元素：

service selector / 服务选择算符
service port

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

小知识：Pod 中的端口定义是有名字的，可以在 Service 的 targetPort 属性中引用这些名称。这样可以只修改pod定义，service 这边就自动改过来了。

没有选择算符的 Service

服务没有选择算符时，不会自动创建相应的 EndpointSlice（和旧版 Endpoint）对象。可以通过手动添加 EndpointSlice 对象，将服务手动映射到运行该服务的网络地址和端口

发布服务（服务类型）

Kubernetes ServiceTypes 允许指定你所需要的 Service 类型。

Type 的取值以及行为如下：

ClusterIP：通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。这也是你没有为服务显式指定 type 时使用的默认值。
NodePort：通过每个节点上的 IP 和静态端口（NodePort）暴露服务。为了让节点端口可用，Kubernetes 设置了集群 IP 地址，这等同于你请求 type: ClusterIP 的服务。
LoadBalancer：使用云提供商的负载均衡器向外部暴露服务。外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上。
ExternalName：通过返回 CNAME 记录和对应值，可以将服务映射到 externalName 字段的内容（例如，foo.bar.example.com）。无需创建任何类型代理。

特别注意： type 字段被设计为嵌套功能 - 每个级别都添加到前一个级别。

也可以使用 Ingress 来暴露自己的服务。

NodePort 类型

如果你将 type 字段设置为 NodePort，则 Kubernetes 控制平面将在 --service-node-port-range 标志指定的范围内分配端口（默认值：30000-32767）。

选择你自己的端口

如果需要特定的端口号，你可以在 nodePort 字段中指定一个值。

需要自己注意可能发生的端口冲突
必须使用有效的端口号，该端口号在配置用于 NodePort 的范围内。

Docs: 在 ubuntu 上安装 kubectl

Mon, 01 Feb 2021 00:00:00 +0000

参考 Kubernetes 官方文档:

https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/

分步骤安装

和后面安装 kubeadm 方式一样，只是这里只需要安装 kubectl 一个工具，不需要安装 kubeadm 和 kublete

执行如下命令：

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl

curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update

k8s 暂时固定使用 1.23.14 版本：

sudo apt-get install kubectl=1.23.14-00
# sudo apt-get install kubelet=1.23.14-00 kubeadm=1.23.14-00 kubectl=1.23.14-00

直接安装

不推荐这样安装，会安装最新版本，而且安装目录是 /usr/local/bin/ 。

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
rm kubectl

如果 /usr/local/bin/ 不在 path 路径下，则需要修改一下 path：

export PATH=/usr/local/bin:$PATH

验证一下：

kubectl version --output=yaml

输出为：

clientVersion:
  buildDate: "2023-06-14T09:53:42Z"
  compiler: gc
  gitCommit: 25b4e43193bcda6c7328a6d147b1fb73a33f1598
  gitTreeState: clean
  gitVersion: v1.27.3
  goVersion: go1.20.5
  major: "1"
  minor: "27"
  platform: linux/amd64
kustomizeVersion: v5.0.1

The connection to the server localhost:8080 was refused - did you specify the right host or port?

配置

oh-my-zsh自动完成

在使用 oh-my-zsh 之后，会更加的简单（强烈推荐使用 oh-my-zsh ），只要在 oh-my-zsh 的 plugins 列表中增加 kubectl 即可。

然后，在 ~/.zshrc 中增加以下内容:

# k8s auto complete
alias k=kubectl
complete -F __start_kubectl k

source ~/.zshrc 之后即可使用，此时用 k 这个别名来执行 kubectl 命令时也可以实现自动完成，非常的方便。

Source: 概述

Mon, 01 Feb 2021 00:00:00 +0000

Client: controller-runtime简介

Mon, 01 Feb 2021 00:00:00 +0000

正如你在第1章中所看到的，Controller Manager 是 Kubernetes 架构的一个重要部分。它嵌入了几个 Controller，每个控制器的作用是观察特定高层资源（Deployments 等）的实例，并使用低层资源（Pod等）来实现这些高层实例。

举例，Kubernetes 用户在部署无状态的应用程序时可以创建 Deployment。这个 Deployment 定义了 Pod 模板，用来在集群中创建 Pod 以及一些规范。以下是最重要的规格：

副本的数量：控制器必须为 Deployment 实例部署相同的 Pod。
部署策略：当 Pod 模板更新时，Pod 被替换的方式。
默认策略：滚动更新（Rolling Update）可用于在不中断服务的情况下将应用程序更新到新版本，它接受各种参数。还存在一个更简单的策略：Recreate，它将首先停止Pod，然后再开始替换它。

Deployment 控制器将创建 ReplicaSet 资源的实例，每个新版本的 Pod 模板都有一个，并更新这些 ReplicaSets 的副本数量，以满足副本和策略规范。你会发现退役版本的 ReplicaSet 的副本数为零，而实际应用版本的 ReplicaSet 的副本数为正数。在滚动更新期间，两个 ReplicaSets 将拥有正数的副本（新的副本数量增加，以前的副本数量减少），以便能够在两个版本之间过渡而不中断服务。

在它这边，ReplicaSet 控制器将负责维护由 Deployment 控制器创建的每个 ReplicaSet 实例所要求的 Pod 副本数量。

第8章已经表明，可以定义新的 Kubernetes 资源来扩展 Kubernetes 的 API。即使有原生控制器管理器运行控制器来处理原生 Kubernetes 资源，你也需要编写控制器来处理自定义资源。

一般来说，这样的控制器被称为 operator，处理第三方资源，并为处理原生 Kubernetes 资源的控制器保留 Controller 这个名字。

Client-go 库提供了使用 Go 语言编写控制器和 operator 的工具，controller-runtime 库利用这些工具提供围绕控制器模式的抽象，帮助你编写 operator 。这个库可以用下面的命令来安装：

go get sigs.k8s.io/controller-runtime@v0.13.0

你可以从 github.com/kubernetes-sigs/controller-runtime/releases 的源码库中获得可用的修订版。

Client: client-go介绍

Mon, 01 Feb 2021 00:00:00 +0000

client-go是一个调用kubernetes集群资源对象API的客户端，即通过client-go实现对kubernetes集群中资源对象（包括deployment、service、ingress、replicaSet、pod、namespace、node等）的增删改查等操作。大部分对kubernetes进行前置API封装的二次开发都通过client-go这个第三方包来实现。

Client: controller-runtime介绍

Mon, 01 Feb 2021 00:00:00 +0000

Kubernetes controller-runtime 项目是一套用于构建 controller 控制器的 Go 库。它被 Kubebuilder 和 operator SDK 所使用。对于新项目来说，这两个项目都是一个很好的起点。

Concepts: 理解 Kubernetes 对象

Mon, 01 Feb 2021 00:00:00 +0000

https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/

理解 Kubernetes 对象

在 Kubernetes 系统中，Kubernetes 对象 是持久化的实体。 Kubernetes 使用这些实体去表示整个集群的状态。比较特别地是，它们描述了如下信息：

哪些容器化应用正在运行（以及在哪些节点上运行）
可以被应用使用的资源
关于应用运行时表现的策略，比如重启策略、升级策略以及容错策略

Kubernetes 对象是“目标性记录” —— 一旦创建该对象，Kubernetes 系统将不断工作以确保该对象存在。通过创建对象，你就是在告知 Kubernetes 系统，你想要的集群工作负载状态看起来应是什么样子的，这就是 Kubernetes 集群所谓的 期望状态（Desired State）。

对象规约（Spec）与状态（Status）

几乎每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置：对象 spec（规约）和对象 status（状态）。对于具有 spec 的对象，你必须在创建对象时设置其内容，描述你希望对象所具有的特征：期望状态（Desired State）。

status 描述了对象的当前状态（Current State），它是由 Kubernetes 系统和组件设置并更新的。在任何时刻，Kubernetes 控制平面都一直都在积极地管理着对象的实际状态，以使之达成期望状态。

例如，Kubernetes 中的 Deployment 对象能够表示运行在集群中的应用。当创建 Deployment 时，可能会去设置 Deployment 的 spec，以指定该应用要有 3 个副本运行。 Kubernetes 系统读取 Deployment 的 spec，并启动我们所期望的应用的 3 个实例 —— 更新状态以与规约相匹配。如果这些实例中有的失败了（一种状态变更），Kubernetes 系统会通过执行修正操作来响应 spec 和状态间的不一致 —— 意味着它会启动一个新的实例来替换。

笔记：spec 必须在创建对象时设置，这是期望状态（Desired State）。status 是当前状态（Current State），由 Kubernetes 系统和组件设置并更新的。

描述 Kubernetes 对象

创建 Kubernetes 对象时，必须提供对象的 spec，用来描述该对象的期望状态，以及关于对象的一些基本信息（例如名称）。当使用 Kubernetes API 创建对象时（直接创建，或经由 kubectl）， API 请求必须在请求本体中包含 JSON 格式的信息。 大多数情况下，你需要提供 .yaml 文件为 kubectl 提供这些信息。 kubectl 在发起 API 请求时，将这些信息转换成 JSON 格式。

必需字段

在想要创建的 Kubernetes 对象所对应的 .yaml 文件中，需要配置的字段如下：

apiVersion - 创建该对象所使用的 Kubernetes API 的版本
kind - 想要创建的对象的类别
metadata - 帮助唯一标识对象的一些数据，包括一个 name 字符串、UID 和可选的 namespace
spec - 你所期望的该对象的状态

笔记

Docs: 安装命令行

Mon, 24 Nov 2025 00:00:00 +0000

参考： https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/

安装 kubeadm / kubelet / kubectl

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gpg

假定要安装的 kubernetes 版本为 1.35:

export K8S_VERSION=1.35

# sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v${K8S_VERSION}/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v${K8S_VERSION}/deb/ /" | sudo tee /etc/apt/sources.list.d/kubernetes.list

开始安装 kubelet kubeadm kubectl：

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl

禁止这三个程序的自动更新：

sudo apt-mark hold kubelet kubeadm kubectl

验证安装：

kubectl version --client && echo && kubeadm version

输出为：

Client Version: v1.35.4
Kustomize Version: v5.7.1

kubeadm version: &version.Info{Major:"1", Minor:"35", EmulationMajor:"", EmulationMinor:"", MinCompatibilityMajor:"", MinCompatibilityMinor:"", GitVersion:"v1.35.4", GitCommit:"7b8c6cf0edd376b3d7c2f255142977c7f93db258", GitTreeState:"clean", BuildDate:"2026-04-15T18:03:27Z", GoVersion:"go1.25.9", Compiler:"gc", Platform:"linux/amd64"}

在运行 kubeadm 之前，先启动 kubelet 服务：

sudo systemctl enable --now kubelet

安装后配置

优化 zsh

vi ~/.zshrc

增加以下内容:

# k8s auto complete
alias k=kubectl
complete -F __start_kubectl k

执行：

source ~/.zshrc

之后即可使用，此时用 k 这个别名来执行 kubectl 命令时也可以实现自动完成，非常的方便。

取消更新

kubeadm / kubelet / kubectl 的版本没有必要升级到最新，因此可以取消他们的自动更新。

sudo vi /etc/apt/sources.list.d/kubernetes.list

注释掉里面的内容。

备注：前面执行 apt-mark hold 后已经不会再更新了，但依然会拖慢 apt update 的速度，因此还是需要手动注释。

常见问题

prod-cdn.packages.k8s.io 无法访问

偶然会遇到 prod-cdn.packages.k8s.io 无法访问的问题，此时的报错如下：

sudo apt-get update
Hit:1 http://mirrors.ustc.edu.cn/debian bookworm InRelease
Hit:2 http://mirrors.ustc.edu.cn/debian bookworm-updates InRelease
Hit:3 http://security.debian.org/debian-security bookworm-security InRelease
Ign:4 https://prod-cdn.packages.k8s.io/repositories/isv:/kubernetes:/core:/stable:/v1.32/deb  InRelease
Ign:4 https://prod-cdn.packages.k8s.io/repositories/isv:/kubernetes:/core:/stable:/v1.32/deb  InRelease
Ign:4 https://prod-cdn.packages.k8s.io/repositories/isv:/kubernetes:/core:/stable:/v1.32/deb  InRelease
Err:4 https://prod-cdn.packages.k8s.io/repositories/isv:/kubernetes:/core:/stable:/v1.32/deb  InRelease
  Could not connect to prod-cdn.packages.k8s.io:443 (221.228.32.13), connection timed out
Reading package lists... Done
W: Failed to fetch https://pkgs.k8s.io/core:/stable:/v1.32/deb/InRelease  Could not connect to prod-cdn.packages.k8s.io:443 (221.228.32.13), connection timed out
W: Some index files failed to download. They have been ignored, or old ones used instead.

首先排除是网络问题，因为实际配好网络代理，也依然无法访问。

后来发现，在不同地区的机器上 ping prod-cdn.packages.k8s.io 的 ip 地址是不一样的，

$ ping prod-cdn.packages.k8s.io

Pinging dkhzw6k7x6ord.cloudfront.net [108.139.10.84] with 32 bytes of data:
Reply from 108.139.10.84: bytes=32 time=164ms TTL=242
Reply from 108.139.10.84: bytes=32 time=166ms TTL=242
......

# 这个地址无法访问
$ ping prod-cdn.packages.k8s.io
PING dkhzw6k7x6ord.cloudfront.net (221.228.32.13) 56(84) bytes of data.
64 bytes from 221.228.32.13 (221.228.32.13): icmp_seq=1 ttl=57 time=9.90 ms
64 bytes from 221.228.32.13 (221.228.32.13): icmp_seq=2 ttl=57 time=11.4 ms
......

因此考虑通过修改 /etc/hosts 文件来避开 dns 解析的问题：

sudo vi /etc/hosts

添加如下内容：

108.139.10.84 prod-cdn.packages.k8s.io

这样在出现问题的这台机器上，强制将 prod-cdn.packages.k8s.io 解析到 108.139.10.84 这个 ip 地址，这样就可以访问了。

Source: types.go

Wed, 14 May 2025 00:00:00 +0000

AdmissionReview

AdmissionReview 描述了准入审查请求/应答。

// AdmissionReview describes an admission review request/response.
type AdmissionReview struct {
	metav1.TypeMeta `json:",inline"`
	// Request describes the attributes for the admission request.
	// +optional
	Request *AdmissionRequest `json:"request,omitempty" protobuf:"bytes,1,opt,name=request"`
	// Response describes the attributes for the admission response.
	// +optional
	Response *AdmissionResponse `json:"response,omitempty" protobuf:"bytes,2,opt,name=response"`
}

AdmissionRequest

dmissionRequest 描述了准入请求的准入属性

type AdmissionRequest struct {
	// UID 是单个请求/响应的唯一标识符。它允许我们区分其他方面相同的请求实例
	//（并行请求、先前请求未修改时的请求等）
	// UID 用于跟踪 KAS 和 WebHook 之间的往返（请求/响应），而不是用户请求
	// 它适合在 webhook 和 apiserver 之间关联日志条目，用于审计或调试
	UID types.UID `json:"uid" protobuf:"bytes,1,opt,name=uid"`
	// Kind 是被提交对象的完全限定类型（例如 v1.Pod 或 autoscaling.v1.Scale）
	Kind metav1.GroupVersionKind `json:"kind" protobuf:"bytes,2,opt,name=kind"`
	// Resource 是被请求的完全限定资源（例如 v1.pods）
	Resource metav1.GroupVersionResource `json:"resource" protobuf:"bytes,3,opt,name=resource"`
	// SubResource 是被请求的子资源（如果有）（例如 "status" 或 "scale"）
	// +optional
	SubResource string `json:"subResource,omitempty" protobuf:"bytes,4,opt,name=subResource"`

	// RequestKind 是原始 API 请求的完全限定类型（例如 v1.Pod 或 autoscaling.v1.Scale）
	// 如果指定且与 "kind" 中的值不同，则表示执行了等效匹配和转换
	//
	// 例如，如果 deployments 可以通过 apps/v1 和 apps/v1beta1 修改，并且 webhook 注册了规则
	// `apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"]` 和 `matchPolicy: Equivalent`，
	// 那么发送到 apps/v1beta1 deployments 的 API 请求会被转换并发送到 webhook，
	// 其中 `kind: {group:"apps", version:"v1", kind:"Deployment"}`（匹配 webhook 注册的规则），
	// 而 `requestKind: {group:"apps", version:"v1beta1", kind:"Deployment"}`（表示原始 API 请求的类型）
	//
	// 更多详情请参阅 webhook 配置类型中 "matchPolicy" 字段的文档
	// +optional
	RequestKind *metav1.GroupVersionKind `json:"requestKind,omitempty" protobuf:"bytes,13,opt,name=requestKind"`
	// RequestResource 是原始 API 请求的完全限定资源（例如 v1.pods）
	// 如果指定且与 "resource" 中的值不同，则表示执行了等效匹配和转换
	//
	// 例如，如果 deployments 可以通过 apps/v1 和 apps/v1beta1 修改，并且 webhook 注册了规则
	// `apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"]` 和 `matchPolicy: Equivalent`，
	// 那么发送到 apps/v1beta1 deployments 的 API 请求会被转换并发送到 webhook，
	// 其中 `resource: {group:"apps", version:"v1", resource:"deployments"}`（匹配 webhook 注册的资源），
	// 而 `requestResource: {group:"apps", version:"v1beta1", resource:"deployments"}`（表示原始 API 请求的资源）
	//
	// 更多详情请参阅 webhook 配置类型中 "matchPolicy" 字段的文档
	// +optional
	RequestResource *metav1.GroupVersionResource `json:"requestResource,omitempty" protobuf:"bytes,14,opt,name=requestResource"`
	// RequestSubResource 是原始 API 请求的子资源名称（如果有）（例如 "status" 或 "scale"）
	// 如果指定且与 "subResource" 中的值不同，则表示执行了等效匹配和转换
	// 更多详情请参阅 webhook 配置类型中 "matchPolicy" 字段的文档
	// +optional
	RequestSubResource string `json:"requestSubResource,omitempty" protobuf:"bytes,15,opt,name=requestSubResource"`

	// Name 是请求中呈现的对象名称。在 CREATE 操作中，客户端可以省略名称，
	// 依赖服务器生成名称。如果是这种情况，此字段将包含空字符串
	// +optional
	Name string `json:"name,omitempty" protobuf:"bytes,5,opt,name=name"`
	// Namespace 是与请求关联的命名空间（如果有）
	// +optional
	Namespace string `json:"namespace,omitempty" protobuf:"bytes,6,opt,name=namespace"`
	// Operation 是正在执行的操作。这可能与请求的操作不同
	// 例如，一个 patch 可能导致 CREATE 或 UPDATE 操作
	Operation Operation `json:"operation" protobuf:"bytes,7,opt,name=operation"`
	// UserInfo 是关于请求用户的信息
	UserInfo authenticationv1.UserInfo `json:"userInfo" protobuf:"bytes,8,opt,name=userInfo"`
	// Object 是来自传入请求的对象
	// +optional
	Object runtime.RawExtension `json:"object,omitempty" protobuf:"bytes,9,opt,name=object"`
	// OldObject 是现有对象。仅对 DELETE 和 UPDATE 请求填充
	// +optional
	OldObject runtime.RawExtension `json:"oldObject,omitempty" protobuf:"bytes,10,opt,name=oldObject"`
	// DryRun 表示此请求的修改肯定不会持久化
	// 默认为 false
	// +optional
	DryRun *bool `json:"dryRun,omitempty" protobuf:"varint,11,opt,name=dryRun"`
	// Options 是正在执行的操作的操作选项结构
	// 例如 `meta.k8s.io/v1.DeleteOptions` 或 `meta.k8s.io/v1.CreateOptions`。这可能与
	// 调用者提供的选项不同。例如，对于 patch 请求，执行的操作可能是 CREATE，
	// 在这种情况下，Options 将是 `meta.k8s.io/v1.CreateOptions`，即使调用者提供了 `meta.k8s.io/v1.PatchOptions`
	// +optional
	Options runtime.RawExtension `json:"options,omitempty" protobuf:"bytes,12,opt,name=options"`
}

AdmissionResponse

// AdmissionResponse 描述了一个准入响应
type AdmissionResponse struct {
	// UID 是单个请求/响应的标识符
	// 必须从对应的 AdmissionRequest 中复制过来
	UID types.UID `json:"uid" protobuf:"bytes,1,opt,name=uid"`

	// Allowed 表示是否允许该准入请求
	Allowed bool `json:"allowed" protobuf:"varint,2,opt,name=allowed"`

	// Result 包含关于为什么拒绝准入请求的额外细节
	// 如果 "Allowed" 为 "true"，则不会参考此字段
	// +optional
	Result *metav1.Status `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`

	// patch 内容体。目前我们只支持实现了 RFC 6902 的 "JSONPatch"
	// +optional
	Patch []byte `json:"patch,omitempty" protobuf:"bytes,4,opt,name=patch"`

	// patch 类型。目前我们只允许 "JSONPatch"
	// +optional
	PatchType *PatchType `json:"patchType,omitempty" protobuf:"bytes,5,opt,name=patchType"`

	// AuditAnnotations 是由远程准入控制器设置的非结构化键值映射（例如 error=image-blacklisted）
	// MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 准入控制器会在键前加上
	// 准入 webhook 名称（例如 imagepolicy.example.com/error=image-blacklisted）
	// 准入 webhook 提供 AuditAnnotations 来为此请求的审计日志添加上下文
	// +optional
	AuditAnnotations map[string]string `json:"auditAnnotations,omitempty" protobuf:"bytes,6,opt,name=auditAnnotations"`

	// warnings 是要返回给请求 API 客户端的警告消息列表
	// 警告消息描述了 API 请求客户端应该纠正或注意的问题
	// 尽可能将警告限制在 120 个字符以内
	// 超过 256 个字符的警告和大量警告可能会被截断
	// +optional
	Warnings []string `json:"warnings,omitempty" protobuf:"bytes,7,rep,name=warnings"`
}

// PatchType is the type of patch being used to represent the mutated object
type PatchType string

// PatchType constants.
const (
	PatchTypeJSONPatch PatchType = "JSONPatch"
)

Source: types.go

Wed, 14 May 2025 00:00:00 +0000

WebhookClientConfig

AdmissionReview 描述了准入审查请求/应答。


// WebhookClientConfig contains the information to make a TLS
// connection with the webhook
type WebhookClientConfig struct {
	// `url` gives the location of the webhook, in standard URL form
	// (`scheme://host:port/path`). Exactly one of `url` or `service`
	// must be specified.
	//
	// The `host` should not refer to a service running in the cluster; use
	// the `service` field instead. The host might be resolved via external
	// DNS in some apiservers (e.g., `kube-apiserver` cannot resolve
	// in-cluster DNS as that would be a layering violation). `host` may
	// also be an IP address.
	//
	// Please note that using `localhost` or `127.0.0.1` as a `host` is
	// risky unless you take great care to run this webhook on all hosts
	// which run an apiserver which might need to make calls to this
	// webhook. Such installs are likely to be non-portable, i.e., not easy
	// to turn up in a new cluster.
	//
	// The scheme must be "https"; the URL must begin with "https://".
	//
	// A path is optional, and if present may be any string permissible in
	// a URL. You may use the path to pass an arbitrary string to the
	// webhook, for example, a cluster identifier.
	//
	// Attempting to use a user or basic auth e.g. "user:password@" is not
	// allowed. Fragments ("#...") and query parameters ("?...") are not
	// allowed, either.
	//
	// +optional
	URL *string `json:"url,omitempty" protobuf:"bytes,3,opt,name=url"`

	// `service` is a reference to the service for this webhook. Either
	// `service` or `url` must be specified.
	//
	// If the webhook is running within the cluster, then you should use `service`.
	//
	// +optional
	Service *ServiceReference `json:"service,omitempty" protobuf:"bytes,1,opt,name=service"`

	// `caBundle` is a PEM encoded CA bundle which will be used to validate the webhook's server certificate.
	// If unspecified, system trust roots on the apiserver are used.
	// +optional
	CABundle []byte `json:"caBundle,omitempty" protobuf:"bytes,2,opt,name=caBundle"`
}

RuleWithOperations

// RuleWithOperations is a tuple of Operations and Resources. It is recommended to make
// sure that all the tuple expansions are valid.
type RuleWithOperations struct {
	// Operations is the operations the admission hook cares about - CREATE, UPDATE, DELETE, CONNECT or *
	// for all of those operations and any future admission operations that are added.
	// If '*' is present, the length of the slice must be one.
	// Required.
	// +listType=atomic
	Operations []OperationType `json:"operations,omitempty" protobuf:"bytes,1,rep,name=operations,casttype=OperationType"`
	// Rule is embedded, it describes other criteria of the rule, like
	// APIGroups, APIVersions, Resources, etc.
	Rule `json:",inline" protobuf:"bytes,2,opt,name=rule"`
}

OperationType

// OperationType specifies an operation for a request.
// +enum
type OperationType string

// The constants should be kept in sync with those defined in k8s.io/kubernetes/pkg/admission/interface.go.
const (
	OperationAll OperationType = "*"
	Create       OperationType = "CREATE"
	Update       OperationType = "UPDATE"
	Delete       OperationType = "DELETE"
	Connect      OperationType = "CONNECT"
)

FailurePolicyType

// FailurePolicyType specifies a failure policy that defines how unrecognized errors from the admission endpoint are handled.
// +enum
type FailurePolicyType string

const (
	// Ignore means that an error calling the webhook is ignored.
	Ignore FailurePolicyType = "Ignore"
	// Fail means that an error calling the webhook causes the admission to fail.
	Fail FailurePolicyType = "Fail"
)

Source: types.go

Wed, 14 May 2025 00:00:00 +0000

APIGroupDiscoveryList


// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object
// +k8s:prerelease-lifecycle-gen:introduced=1.30

// APIGroupDiscoveryList is a resource containing a list of APIGroupDiscovery.
// This is one of the types able to be returned from the /api and /apis endpoint and contains an aggregated
// list of API resources (built-ins, Custom Resource Definitions, resources from aggregated servers)
// that a cluster supports.
type APIGroupDiscoveryList struct {
	v1.TypeMeta `json:",inline"`
	// ResourceVersion will not be set, because this does not have a replayable ordering among multiple apiservers.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
	// +optional
	v1.ListMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`
	// items is the list of groups for discovery. The groups are listed in priority order.
	Items []APIGroupDiscovery `json:"items" protobuf:"bytes,2,rep,name=items"`
}

APIGroupDiscovery

// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object
// +k8s:prerelease-lifecycle-gen:introduced=1.30

// APIGroupDiscovery holds information about which resources are being served for all version of the API Group.
// It contains a list of APIVersionDiscovery that holds a list of APIResourceDiscovery types served for a version.
// Versions are in descending order of preference, with the first version being the preferred entry.
type APIGroupDiscovery struct {
	v1.TypeMeta `json:",inline"`
	// Standard object's metadata.
	// The only field completed will be name. For instance, resourceVersion will be empty.
	// name is the name of the API group whose discovery information is presented here.
	// name is allowed to be "" to represent the legacy, ungroupified resources.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
	// +optional
	v1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`
	// versions are the versions supported in this group. They are sorted in descending order of preference,
	// with the preferred version being the first entry.
	// +listType=map
	// +listMapKey=version
	Versions []APIVersionDiscovery `json:"versions,omitempty" protobuf:"bytes,2,rep,name=versions"`
}

Source: types.go

Wed, 14 May 2025 00:00:00 +0000

StorageVersion

// Storage version of a specific resource.
type StorageVersion struct {
	metav1.TypeMeta `json:",inline"`
	// The name is <group>.<resource>.
	metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`

	// Spec is an empty spec. It is here to comply with Kubernetes API style.
	Spec StorageVersionSpec `json:"spec" protobuf:"bytes,2,opt,name=spec"`

	// API server instances report the version they can decode and the version they
	// encode objects to when persisting objects in the backend.
	Status StorageVersionStatus `json:"status" protobuf:"bytes,3,opt,name=status"`
}

StorageVersionList

// A list of StorageVersions.
type StorageVersionList struct {
	metav1.TypeMeta `json:",inline"`
	// Standard list metadata.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
	// +optional
	metav1.ListMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`
	// Items holds a list of StorageVersion
	Items []StorageVersion `json:"items" protobuf:"bytes,2,rep,name=items"`
}

Source: types.go

Wed, 14 May 2025 00:00:00 +0000

StatefulSet

// StatefulSet represents a set of pods with consistent identities.
// Identities are defined as:
//   - Network: A single stable DNS and hostname.
//   - Storage: As many VolumeClaims as requested.
//
// The StatefulSet guarantees that a given network identity will always
// map to the same storage identity.
type StatefulSet struct {
	metav1.TypeMeta `json:",inline"`
	// Standard object's metadata.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
	// +optional
	metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`

	// Spec defines the desired identities of pods in this set.
	// +optional
	Spec StatefulSetSpec `json:"spec,omitempty" protobuf:"bytes,2,opt,name=spec"`

	// Status is the current status of Pods in this StatefulSet. This data
	// may be out of date by some window of time.
	// +optional
	Status StatefulSetStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
}

Deployment

// Deployment enables declarative updates for Pods and ReplicaSets.
type Deployment struct {
	metav1.TypeMeta `json:",inline"`
	// Standard object's metadata.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
	// +optional
	metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`

	// Specification of the desired behavior of the Deployment.
	// +optional
	Spec DeploymentSpec `json:"spec,omitempty" protobuf:"bytes,2,opt,name=spec"`

	// Most recently observed status of the Deployment.
	// +optional
	Status DeploymentStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
}

DaemonSet

// DaemonSet represents the configuration of a daemon set.
type DaemonSet struct {
	metav1.TypeMeta `json:",inline"`
	// Standard object's metadata.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
	// +optional
	metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`

	// The desired behavior of this daemon set.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
	// +optional
	Spec DaemonSetSpec `json:"spec,omitempty" protobuf:"bytes,2,opt,name=spec"`

	// The current status of this daemon set. This data may be
	// out of date by some window of time.
	// Populated by the system.
	// Read-only.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
	// +optional
	Status DaemonSetStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
}

ReplicaSet

// ReplicaSet ensures that a specified number of pod replicas are running at any given time.
type ReplicaSet struct {
	metav1.TypeMeta `json:",inline"`

	// If the Labels of a ReplicaSet are empty, they are defaulted to
	// be the same as the Pod(s) that the ReplicaSet manages.
	// Standard object's metadata.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
	// +optional
	metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`

	// Spec defines the specification of the desired behavior of the ReplicaSet.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
	// +optional
	Spec ReplicaSetSpec `json:"spec,omitempty" protobuf:"bytes,2,opt,name=spec"`

	// Status is the most recently observed status of the ReplicaSet.
	// This data may be out of date by some window of time.
	// Populated by the system.
	// Read-only.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
	// +optional
	Status ReplicaSetStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
}

ControllerRevision


// ControllerRevision implements an immutable snapshot of state data. Clients
// are responsible for serializing and deserializing the objects that contain
// their internal state.
// Once a ControllerRevision has been successfully created, it can not be updated.
// The API Server will fail validation of all requests that attempt to mutate
// the Data field. ControllerRevisions may, however, be deleted. Note that, due to its use by both
// the DaemonSet and StatefulSet controllers for update and rollback, this object is beta. However,
// it may be subject to name and representation changes in future releases, and clients should not
// depend on its stability. It is primarily for internal use by controllers.
type ControllerRevision struct {
	metav1.TypeMeta `json:",inline"`
	// Standard object's metadata.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
	// +optional
	metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`

	// Data is the serialized representation of the state.
	Data runtime.RawExtension `json:"data,omitempty" protobuf:"bytes,2,opt,name=data"`

	// Revision indicates the revision of the state represented by Data.
	Revision int64 `json:"revision" protobuf:"varint,3,opt,name=revision"`
}

Source: types.go

Wed, 14 May 2025 00:00:00 +0000

TokenReview

type TokenReview struct {
	metav1.TypeMeta `json:",inline"`
	// Standard object's metadata.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
	// +optional
	metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`

	// Spec holds information about the request being evaluated
	Spec TokenReviewSpec `json:"spec" protobuf:"bytes,2,opt,name=spec"`

	// Status is filled in by the server and indicates whether the request can be authenticated.
	// +optional
	Status TokenReviewStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
}

TokenRequest

// TokenRequest requests a token for a given service account.
type TokenRequest struct {
	metav1.TypeMeta `json:",inline"`
	// Standard object's metadata.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
	// +optional
	metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`

	// Spec holds information about the request being evaluated
	Spec TokenRequestSpec `json:"spec" protobuf:"bytes,2,opt,name=spec"`

	// Status is filled in by the server and indicates whether the token can be authenticated.
	// +optional
	Status TokenRequestStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
}

SelfSubjectReview

// SelfSubjectReview contains the user information that the kube-apiserver has about the user making this request.
// When using impersonation, users will receive the user info of the user being impersonated.  If impersonation or
// request header authentication is used, any extra keys will have their case ignored and returned as lowercase.
type SelfSubjectReview struct {
	metav1.TypeMeta `json:",inline"`
	// Standard object's metadata.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
	// +optional
	metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`
	// Status is filled in by the server with the user attributes.
	Status SelfSubjectReviewStatus `json:"status,omitempty" protobuf:"bytes,2,opt,name=status"`
}

Source: types.go

Wed, 14 May 2025 00:00:00 +0000

TokenReview

TokenRequest

// TokenRequest requests a token for a given service account.
type TokenRequest struct {
	metav1.TypeMeta `json:",inline"`
	// Standard object's metadata.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
	// +optional
	metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`

	// Spec holds information about the request being evaluated
	Spec TokenRequestSpec `json:"spec" protobuf:"bytes,2,opt,name=spec"`

	// Status is filled in by the server and indicates whether the token can be authenticated.
	// +optional
	Status TokenRequestStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
}

SelfSubjectReview

// SelfSubjectReview contains the user information that the kube-apiserver has about the user making this request.
// When using impersonation, users will receive the user info of the user being impersonated.  If impersonation or
// request header authentication is used, any extra keys will have their case ignored and returned as lowercase.
type SelfSubjectReview struct {
	metav1.TypeMeta `json:",inline"`
	// Standard object's metadata.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
	// +optional
	metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`
	// Status is filled in by the server with the user attributes.
	Status SelfSubjectReviewStatus `json:"status,omitempty" protobuf:"bytes,2,opt,name=status"`
}

Source: 代码仓库

Wed, 14 May 2025 00:00:00 +0000

kubernetes/kubernetes

https://github.com/kubernetes/kubernetes

从它的 go.mod 文件可以看到，它依赖了大量的 k8s 的组件：

	k8s.io/api v0.0.0
	k8s.io/apiextensions-apiserver v0.0.0
	k8s.io/apimachinery v0.0.0
	k8s.io/apiserver v0.0.0
	k8s.io/cli-runtime v0.0.0
	k8s.io/client-go v0.0.0
	k8s.io/cloud-provider v0.0.0
	k8s.io/cluster-bootstrap v0.0.0
	k8s.io/code-generator v0.0.0
	k8s.io/component-base v0.0.0
	k8s.io/component-helpers v0.0.0
	k8s.io/controller-manager v0.0.0
	k8s.io/cri-api v0.0.0
	k8s.io/cri-client v0.0.0
	k8s.io/csi-translation-lib v0.0.0
	k8s.io/dynamic-resource-allocation v0.0.0
	k8s.io/endpointslice v0.0.0
	k8s.io/externaljwt v0.0.0
	k8s.io/klog/v2 v2.130.1
	k8s.io/kms v0.0.0
	k8s.io/kube-aggregator v0.0.0
	k8s.io/kube-controller-manager v0.0.0
	k8s.io/kube-openapi v0.0.0-20250318190949-c8a335a9a2ff
	k8s.io/kube-proxy v0.0.0
	k8s.io/kube-scheduler v0.0.0
	k8s.io/kubectl v0.0.0
	k8s.io/kubelet v0.0.0
	k8s.io/metrics v0.0.0
	k8s.io/mount-utils v0.0.0
	k8s.io/pod-security-admission v0.0.0
	k8s.io/sample-apiserver v0.0.0
	k8s.io/system-validators v1.9.1
	k8s.io/utils v0.0.0-20250502105355-0f33e8f1c979

而这些又被 replace 到本地的 ./staging/src/k8s.io/ 目录下：

replace (
	k8s.io/api => ./staging/src/k8s.io/api
	k8s.io/apiextensions-apiserver => ./staging/src/k8s.io/apiextensions-apiserver
	k8s.io/apimachinery => ./staging/src/k8s.io/apimachinery
	k8s.io/apiserver => ./staging/src/k8s.io/apiserver
	k8s.io/cli-runtime => ./staging/src/k8s.io/cli-runtime
	k8s.io/client-go => ./staging/src/k8s.io/client-go
	k8s.io/cloud-provider => ./staging/src/k8s.io/cloud-provider
	k8s.io/cluster-bootstrap => ./staging/src/k8s.io/cluster-bootstrap
	k8s.io/code-generator => ./staging/src/k8s.io/code-generator
	k8s.io/component-base => ./staging/src/k8s.io/component-base
	k8s.io/component-helpers => ./staging/src/k8s.io/component-helpers
	k8s.io/controller-manager => ./staging/src/k8s.io/controller-manager
	k8s.io/cri-api => ./staging/src/k8s.io/cri-api
	k8s.io/cri-client => ./staging/src/k8s.io/cri-client
	k8s.io/csi-translation-lib => ./staging/src/k8s.io/csi-translation-lib
	k8s.io/dynamic-resource-allocation => ./staging/src/k8s.io/dynamic-resource-allocation
	k8s.io/endpointslice => ./staging/src/k8s.io/endpointslice
	k8s.io/externaljwt => ./staging/src/k8s.io/externaljwt
	k8s.io/kms => ./staging/src/k8s.io/kms
	k8s.io/kube-aggregator => ./staging/src/k8s.io/kube-aggregator
	k8s.io/kube-controller-manager => ./staging/src/k8s.io/kube-controller-manager
	k8s.io/kube-proxy => ./staging/src/k8s.io/kube-proxy
	k8s.io/kube-scheduler => ./staging/src/k8s.io/kube-scheduler
	k8s.io/kubectl => ./staging/src/k8s.io/kubectl
	k8s.io/kubelet => ./staging/src/k8s.io/kubelet
	k8s.io/metrics => ./staging/src/k8s.io/metrics
	k8s.io/mount-utils => ./staging/src/k8s.io/mount-utils
	k8s.io/pod-security-admission => ./staging/src/k8s.io/pod-security-admission
)

Docs: 预热安装 kubenetes

Mon, 12 May 2025 00:00:00 +0000

原理

所谓预热安装，就是在在线安装的基础上，在执行 kubeadmin init 之前，提前准备好所有的安装文件和镜像文件，然后制作成 pve 模板。

之后就可以重用该模板，在需要时创建虚拟机，在虚拟机中执行 kubeadmin init 即可快速安装 kubenetes。

原则上，在执行 kubeadmin init 之前的各种准备工作都可以参考在线安装的方式。而在 kubeadmin init 之后的安装工作，就只能通过提前准备安装文件和提前下载镜像文件等方式来加速。为最大化提升速度，所有的镜像文件都将通过 habor 进行代理。

准备工作

安装 docker：参考 https://skyao.net/learning-docker/docs/installation/debian13/ ，在线安装和离线安装都可以。
安装 kubeadm：参考前面的在线安装方式，或者直接用后面的离线安装方式，将 cri-dockerd / helm 和kubeadm / kubelete / kubectl 安装好。

预下载镜像文件

k8s cluster

kubeadm config images pull --cri-socket unix:///var/run/cri-dockerd.sock --config=kubeadm.yaml

这样就可以提前下载好 kubeadm init 时需要的镜像文件：

[config/images] Pulled 192.168.3.193:5000/k8s-proxy/kube-apiserver:v1.35.4
[config/images] Pulled 192.168.3.193:5000/k8s-proxy/kube-controller-manager:v1.35.4
[config/images] Pulled 192.168.3.193:5000/k8s-proxy/kube-scheduler:v1.35.4
[config/images] Pulled 192.168.3.193:5000/k8s-proxy/kube-proxy:v1.35.4
[config/images] Pulled 192.168.3.193:5000/k8s-proxy/coredns/coredns:v1.13.1
[config/images] Pulled 192.168.3.193:5000/k8s-proxy/pause:3.10.1
[config/images] Pulled 192.168.3.193:5000/k8s-proxy/etcd:3.6.6-0

准备 kubeadm.yaml 文件备用，内容同在线安装：

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
nodeRegistration:
  criSocket: unix:///var/run/cri-dockerd.sock

---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.35.4
imageRepository: 192.168.3.193:5000/k8s-proxy
networking:
  podSubnet: 10.244.0.0/16
dns:
  imageRepository: 192.168.3.193:5000/k8s-proxy/coredns
  imageTag: v1.13.1
etcd:
  local:
    imageRepository: 192.168.3.193:5000/k8s-proxy
    imageTag: 3.6.6-0

flannel

下载原始的 kube-flannel.yml 文件：

wget https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

修改 kube-flannel.yml, 将原有的镜像文件地址从

image: ghcr.io/flannel-io/flannel:v0.28.4
image: ghcr.io/flannel-io/flannel-cni-plugin:v1.9.1-flannel1

修改为：

image: 192.168.3.193:5000/ghcr.io/flannel-io/flannel:v0.28.4
image: 192.168.3.193:5000/ghcr.io/flannel-io/flannel-cni-plugin:v1.9.1-flannel1

下载 flannel 需要的镜像文件：

docker pull 192.168.3.193:5000/ghcr.io/flannel-io/flannel-cni-plugin:v1.9.1-flannel1
docker pull 192.168.3.193:5000/ghcr.io/flannel-io/flannel:v0.28.4

metrics-server

下载原始的 components.yaml 文件, 保存为 metrics-server-components.yaml：

wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml 
mv components.yaml metrics-server-components.yaml

修改内容如下：

    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=10250
        - --kubelet-preferred-address-types=InternalIP   # 修改
        - --kubelet-use-node-status-port
        - --metric-resolution=15s
        - --kubelet-insecure-tls # 添加
        image: 192.168.3.193:5000/registry.k8s.io/metrics-server/metrics-server:v0.8.1 # 修改

下载 metrics-server 需要的镜像文件：

docker pull 192.168.3.193:5000/registry.k8s.io/metrics-server/metrics-server:v0.8.1

如果制作过程中，下载了多余的镜像，可以用如下命令先清空，再重新拉取需要的镜像：

docker rmi -f $(docker images -q)

安装

手工安装

执行 kubeadm init 命令：

cd ~/work/soft/k8s/

sudo kubeadm init --config=kubeadm.yaml

配置 kube config：

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

配置 flannel 网络：

kubectl apply -f ~/work/soft/k8s/kube-flannel.yml

去除污点：

kubectl taint nodes --all node-role.kubernetes.io/control-plane-

安装 metrics-server：

kubectl apply -f ~/work/soft/k8s/metrics-server-components.yaml

kubectl wait --namespace kube-system \
  --for=condition=Ready \
  --selector=k8s-app=metrics-server \
  --timeout=300s pod
echo "metrics-server installed, have a try:"
echo
echo "kubectl top nodes"
echo
kubectl top nodes
echo
echo "kubectl top pods -n kube-system"
echo
kubectl top pods -n kube-system

脚本自动安装

cd ~/work/soft/k8s/
vi install_k8s_prewarm.zsh

内容如下：

#!/usr/bin/env zsh

# Kubernetes 自动化安装脚本 (Debian 13 + Helm + Metrics Server)
# 使用方法: sudo ./install_k8s_prewarm.zsh

# 获取脚本所在绝对路径
K8S_INSTALL_PATH=$(cd "$(dirname "$0")"; pwd)
MANIFESTS_PATH="$K8S_INSTALL_PATH/menifests"
echo "🔍 检测到安装文件目录: $K8S_INSTALL_PATH"

# 检查是否以 root 执行
if [[ $EUID -ne 0 ]]; then
  echo "❌ 此脚本必须以 root 身份运行"
  exit 1
fi

# 安装日志
mkdir -p "$K8S_INSTALL_PATH/logs"
LOG_FILE="$K8S_INSTALL_PATH/logs/k8s_install_$(date +%Y%m%d_%H%M%S).log"
exec > >(tee -a "$LOG_FILE") 2>&1

echo "📅 开始安装 Kubernetes 集群 - $(date)"
echo "📁 资源目录: $K8S_INSTALL_PATH"

# 步骤1: kubeadm 初始化
echo "🚀 正在初始化 Kubernetes 控制平面..."
kubeadm_init() {
  sudo kubeadm init --config="$MANIFESTS_PATH/kubeadm.yaml"

  if [[ $? -ne 0 ]]; then
    echo "❌ kubeadm init 失败"
    exit 1
  fi
}
kubeadm_init
sleep 3

# 步骤2: 配置 kubectl
echo "⚙️ 为 root 用户配置 kubectl..."
mkdir -p $HOME/.kube
cp /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config
echo "⚙️ 为当前用户配置 kubectl..."
CURRENT_USER_HOME=$(getent passwd $SUDO_USER | cut -d: -f6)
mkdir -p $CURRENT_USER_HOME/.kube
cp /etc/kubernetes/admin.conf $CURRENT_USER_HOME/.kube/config
chown $(id -u $SUDO_USER):$(id -g $SUDO_USER) $CURRENT_USER_HOME/.kube/config

# 步骤3: 安装 Flannel 网络插件
echo "🌐 正在安装 Flannel 网络..."
kubectl apply -f "$MANIFESTS_PATH/kube-flannel.yml" || {
  echo "❌ Flannel 安装失败"
  exit 1
}
sleep 3

# 步骤4: 去除控制平面污点
echo "✨ 去除控制平面污点..."
kubectl taint nodes --all node-role.kubernetes.io/control-plane- || {
  echo "⚠️ 去除污点失败 (可能不影响功能)"
}

# 步骤5: 安装 Metrics Server
echo "📈 正在安装 Metrics Server..."
kubectl apply -f "$MANIFESTS_PATH/metrics-server-components.yaml" || {
  echo "❌ Metrics Server 安装失败"
  exit 1
}

# 等待 Metrics Server 就绪
echo "⏳ 等待 Metrics Server 就绪 (最多5分钟)..."
kubectl rollout status deployment metrics-server \
  --namespace kube-system \
  --timeout=300s || {
  echo "❌ Metrics Server 启动超时"
  exit 1
}

# 验证安装
echo "✅ 安装完成!"
sleep 5
echo ""
echo "🛠️  验证命令:"
echo "kubectl top nodes"
kubectl top nodes
echo ""
echo "kubectl top pods -n kube-system"
kubectl top pods -n kube-system

echo ""
echo "安装日志: $LOG_FILE"

增加执行权限：

chmod +x install_k8s_prewarm.zsh

执行：

sudo ./install_k8s_prewarm.zsh

Source: pod的定义

Tue, 01 Apr 2025 00:00:00 +0000

概述

pod的结构体定义和属性，来自 cursor 的提示，感谢 cursor 的强大。

Pod 是 Kubernetes 中最小的可部署单元，它的定义位于 staging/src/k8s.io/api/core/v1/types.go 文件中。一个 Pod 包含以下主要部分：

基本结构：

type Pod struct {
    metav1.TypeMeta `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`
    Spec PodSpec `json:"spec,omitempty" protobuf:"bytes,2,opt,name=spec"`
    Status PodStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
}

主要组件：

metadata: 包含 Pod 的元数据信息，如名称、命名空间、标签等
spec: Pod 的规格定义，包含以下重要字段：
- containers: Pod 中的容器列表（至少需要一个容器）
- initContainers: 初始化容器列表
- volumes: 可挂载的存储卷列表
- restartPolicy: 重启策略（Always、OnFailure、Never）
- nodeSelector: 节点选择器
- serviceAccountName: 服务账号名称
- securityContext: 安全上下文
- imagePullSecrets: 镜像拉取密钥
- affinity: 亲和性设置
- tolerations: 容忍设置
- 等等…
status: Pod 的当前状态信息，包含：
- phase: Pod 的生命周期阶段（Pending、Running、Succeeded、Failed、Unknown）
- conditions: Pod 的条件状态
- message: 状态描述信息
- reason: 状态原因
- hostIP: 主机 IP
- podIP: Pod IP
- containerStatuses: 容器状态列表
- initContainerStatuses: 初始化容器状态列表
- qosClass: 服务质量等级（Guaranteed、Burstable、BestEffort）

生命周期： Pod 有五个主要阶段：

Pending: Pod 已被系统接受，但容器镜像尚未创建
Running: Pod 已绑定到节点，所有容器已启动
Succeeded: 所有容器已成功终止
Failed: 所有容器已终止，至少有一个容器失败
Unknown: 无法获取 Pod 状态

条件状态： Pod 可以有以下条件状态：

ContainersReady: 所有容器是否就绪
PodInitialized: 所有初始化容器是否成功启动
PodReady: Pod 是否可以服务请求
PodScheduled: Pod 的调度状态
DisruptionTarget: Pod 是否即将被终止
PodReadyToStartContainers: Pod 沙箱是否配置成功
PodResizePending: Pod 是否正在调整大小
PodResizeInProgress: Pod 大小调整是否正在进行

这就是 Kubernetes 中 Pod 的基本定义和结构。Pod 是 Kubernetes 中最小的可部署单元，它可以包含一个或多个容器，这些容器共享网络命名空间和存储卷。

pod 结构体

pod的结构体定义在 staging/src/k8s.io/api/core/v1/pod.go 文件中:

type Pod struct {
	metav1.TypeMeta `json:",inline"`
	// Standard object's metadata.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
	// +optional
	metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`

	// Specification of the desired behavior of the pod.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
	// +optional
	Spec PodSpec `json:"spec,omitempty" protobuf:"bytes,2,opt,name=spec"`

	// Most recently observed status of the pod.
	// This data may not be up to date.
	// Populated by the system.
	// Read-only.
	// More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
	// +optional
	Status PodStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
}

备注: staging/src/k8s.io/api 的代码会被同步到仓库 https://github.com/kubernetes/api 中

PodSpec 结构体

PodSpec 的定义在同一个文件中:

// PodSpec is a description of a pod.
type PodSpec struct {
	// List of volumes that can be mounted by containers belonging to the pod.
	// More info: https://kubernetes.io/docs/concepts/storage/volumes
	// +optional
	// +patchMergeKey=name
	// +patchStrategy=merge,retainKeys
	// +listType=map
	// +listMapKey=name
	Volumes []Volume `json:"volumes,omitempty" patchStrategy:"merge,retainKeys" patchMergeKey:"name" protobuf:"bytes,1,rep,name=volumes"`
	// List of initialization containers belonging to the pod.
	// Init containers are executed in order prior to containers being started. If any
	// init container fails, the pod is considered to have failed and is handled according
	// to its restartPolicy. The name for an init container or normal container must be
	// unique among all containers.
	// Init containers may not have Lifecycle actions, Readiness probes, Liveness probes, or Startup probes.
	// The resourceRequirements of an init container are taken into account during scheduling
	// by finding the highest request/limit for each resource type, and then using the max of
	// that value or the sum of the normal containers. Limits are applied to init containers
	// in a similar fashion.
	// Init containers cannot currently be added or removed.
	// Cannot be updated.
	// More info: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
	// +patchMergeKey=name
	// +patchStrategy=merge
	// +listType=map
	// +listMapKey=name
	InitContainers []Container `json:"initContainers,omitempty" patchStrategy:"merge" patchMergeKey:"name" protobuf:"bytes,20,rep,name=initContainers"`
	// List of containers belonging to the pod.
	// Containers cannot currently be added or removed.
	// There must be at least one container in a Pod.
	// Cannot be updated.
	// +patchMergeKey=name
	// +patchStrategy=merge
	// +listType=map
	// +listMapKey=name
	Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name" protobuf:"bytes,2,rep,name=containers"`
	// List of ephemeral containers run in this pod. Ephemeral containers may be run in an existing
	// pod to perform user-initiated actions such as debugging. This list cannot be specified when
	// creating a pod, and it cannot be modified by updating the pod spec. In order to add an
	// ephemeral container to an existing pod, use the pod's ephemeralcontainers subresource.
	// +optional
	// +patchMergeKey=name
	// +patchStrategy=merge
	// +listType=map
	// +listMapKey=name
	EphemeralContainers []EphemeralContainer `json:"ephemeralContainers,omitempty" patchStrategy:"merge" patchMergeKey:"name" protobuf:"bytes,34,rep,name=ephemeralContainers"`
	// Restart policy for all containers within the pod.
	// One of Always, OnFailure, Never. In some contexts, only a subset of those values may be permitted.
	// Default to Always.
	// More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy
	// +optional
	RestartPolicy RestartPolicy `json:"restartPolicy,omitempty" protobuf:"bytes,3,opt,name=restartPolicy,casttype=RestartPolicy"`
	// Optional duration in seconds the pod needs to terminate gracefully. May be decreased in delete request.
	// Value must be non-negative integer. The value zero indicates stop immediately via
	// the kill signal (no opportunity to shut down).
	// If this value is nil, the default grace period will be used instead.
	// The grace period is the duration in seconds after the processes running in the pod are sent
	// a termination signal and the time when the processes are forcibly halted with a kill signal.
	// Set this value longer than the expected cleanup time for your process.
	// Defaults to 30 seconds.
	// +optional
	TerminationGracePeriodSeconds *int64 `json:"terminationGracePeriodSeconds,omitempty" protobuf:"varint,4,opt,name=terminationGracePeriodSeconds"`
	// Optional duration in seconds the pod may be active on the node relative to
	// StartTime before the system will actively try to mark it failed and kill associated containers.
	// Value must be a positive integer.
	// +optional
	ActiveDeadlineSeconds *int64 `json:"activeDeadlineSeconds,omitempty" protobuf:"varint,5,opt,name=activeDeadlineSeconds"`
	// Set DNS policy for the pod.
	// Defaults to "ClusterFirst".
	// Valid values are 'ClusterFirstWithHostNet', 'ClusterFirst', 'Default' or 'None'.
	// DNS parameters given in DNSConfig will be merged with the policy selected with DNSPolicy.
	// To have DNS options set along with hostNetwork, you have to specify DNS policy
	// explicitly to 'ClusterFirstWithHostNet'.
	// +optional
	DNSPolicy DNSPolicy `json:"dnsPolicy,omitempty" protobuf:"bytes,6,opt,name=dnsPolicy,casttype=DNSPolicy"`
	// NodeSelector is a selector which must be true for the pod to fit on a node.
	// Selector which must match a node's labels for the pod to be scheduled on that node.
	// More info: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
	// +optional
	// +mapType=atomic
	NodeSelector map[string]string `json:"nodeSelector,omitempty" protobuf:"bytes,7,rep,name=nodeSelector"`

	// ServiceAccountName is the name of the ServiceAccount to use to run this pod.
	// More info: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
	// +optional
	ServiceAccountName string `json:"serviceAccountName,omitempty" protobuf:"bytes,8,opt,name=serviceAccountName"`
	// DeprecatedServiceAccount is a deprecated alias for ServiceAccountName.
	// Deprecated: Use serviceAccountName instead.
	// +k8s:conversion-gen=false
	// +optional
	DeprecatedServiceAccount string `json:"serviceAccount,omitempty" protobuf:"bytes,9,opt,name=serviceAccount"`
	// AutomountServiceAccountToken indicates whether a service account token should be automatically mounted.
	// +optional
	AutomountServiceAccountToken *bool `json:"automountServiceAccountToken,omitempty" protobuf:"varint,21,opt,name=automountServiceAccountToken"`

	// NodeName indicates in which node this pod is scheduled.
	// If empty, this pod is a candidate for scheduling by the scheduler defined in schedulerName.
	// Once this field is set, the kubelet for this node becomes responsible for the lifecycle of this pod.
	// This field should not be used to express a desire for the pod to be scheduled on a specific node.
	// https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodename
	// +optional
	NodeName string `json:"nodeName,omitempty" protobuf:"bytes,10,opt,name=nodeName"`
	// Host networking requested for this pod. Use the host's network namespace.
	// If this option is set, the ports that will be used must be specified.
	// Default to false.
	// +k8s:conversion-gen=false
	// +optional
	HostNetwork bool `json:"hostNetwork,omitempty" protobuf:"varint,11,opt,name=hostNetwork"`
	// Use the host's pid namespace.
	// Optional: Default to false.
	// +k8s:conversion-gen=false
	// +optional
	HostPID bool `json:"hostPID,omitempty" protobuf:"varint,12,opt,name=hostPID"`
	// Use the host's ipc namespace.
	// Optional: Default to false.
	// +k8s:conversion-gen=false
	// +optional
	HostIPC bool `json:"hostIPC,omitempty" protobuf:"varint,13,opt,name=hostIPC"`
	// Share a single process namespace between all of the containers in a pod.
	// When this is set containers will be able to view and signal processes from other containers
	// in the same pod, and the first process in each container will not be assigned PID 1.
	// HostPID and ShareProcessNamespace cannot both be set.
	// Optional: Default to false.
	// +k8s:conversion-gen=false
	// +optional
	ShareProcessNamespace *bool `json:"shareProcessNamespace,omitempty" protobuf:"varint,27,opt,name=shareProcessNamespace"`
	// SecurityContext holds pod-level security attributes and common container settings.
	// Optional: Defaults to empty.  See type description for default values of each field.
	// +optional
	SecurityContext *PodSecurityContext `json:"securityContext,omitempty" protobuf:"bytes,14,opt,name=securityContext"`
	// ImagePullSecrets is an optional list of references to secrets in the same namespace to use for pulling any of the images used by this PodSpec.
	// If specified, these secrets will be passed to individual puller implementations for them to use.
	// More info: https://kubernetes.io/docs/concepts/containers/images#specifying-imagepullsecrets-on-a-pod
	// +optional
	// +patchMergeKey=name
	// +patchStrategy=merge
	// +listType=map
	// +listMapKey=name
	ImagePullSecrets []LocalObjectReference `json:"imagePullSecrets,omitempty" patchStrategy:"merge" patchMergeKey:"name" protobuf:"bytes,15,rep,name=imagePullSecrets"`
	// Specifies the hostname of the Pod
	// If not specified, the pod's hostname will be set to a system-defined value.
	// +optional
	Hostname string `json:"hostname,omitempty" protobuf:"bytes,16,opt,name=hostname"`
	// If specified, the fully qualified Pod hostname will be "<hostname>.<subdomain>.<pod namespace>.svc.<cluster domain>".
	// If not specified, the pod will not have a domainname at all.
	// +optional
	Subdomain string `json:"subdomain,omitempty" protobuf:"bytes,17,opt,name=subdomain"`
	// If specified, the pod's scheduling constraints
	// +optional
	Affinity *Affinity `json:"affinity,omitempty" protobuf:"bytes,18,opt,name=affinity"`
	// If specified, the pod will be dispatched by specified scheduler.
	// If not specified, the pod will be dispatched by default scheduler.
	// +optional
	SchedulerName string `json:"schedulerName,omitempty" protobuf:"bytes,19,opt,name=schedulerName"`
	// If specified, the pod's tolerations.
	// +optional
	// +listType=atomic
	Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"`
	// HostAliases is an optional list of hosts and IPs that will be injected into the pod's hosts
	// file if specified.
	// +optional
	// +patchMergeKey=ip
	// +patchStrategy=merge
	// +listType=map
	// +listMapKey=ip
	HostAliases []HostAlias `json:"hostAliases,omitempty" patchStrategy:"merge" patchMergeKey:"ip" protobuf:"bytes,23,rep,name=hostAliases"`
	// If specified, indicates the pod's priority. "system-node-critical" and
	// "system-cluster-critical" are two special keywords which indicate the
	// highest priorities with the former being the highest priority. Any other
	// name must be defined by creating a PriorityClass object with that name.
	// If not specified, the pod priority will be default or zero if there is no
	// default.
	// +optional
	PriorityClassName string `json:"priorityClassName,omitempty" protobuf:"bytes,24,opt,name=priorityClassName"`
	// The priority value. Various system components use this field to find the
	// priority of the pod. When Priority Admission Controller is enabled, it
	// prevents users from setting this field. The admission controller populates
	// this field from PriorityClassName.
	// The higher the value, the higher the priority.
	// +optional
	Priority *int32 `json:"priority,omitempty" protobuf:"bytes,25,opt,name=priority"`
	// Specifies the DNS parameters of a pod.
	// Parameters specified here will be merged to the generated DNS
	// configuration based on DNSPolicy.
	// +optional
	DNSConfig *PodDNSConfig `json:"dnsConfig,omitempty" protobuf:"bytes,26,opt,name=dnsConfig"`
	// If specified, all readiness gates will be evaluated for pod readiness.
	// A pod is ready when all its containers are ready AND
	// all conditions specified in the readiness gates have status equal to "True"
	// More info: https://git.k8s.io/enhancements/keps/sig-network/580-pod-readiness-gates
	// +optional
	// +listType=atomic
	ReadinessGates []PodReadinessGate `json:"readinessGates,omitempty" protobuf:"bytes,28,opt,name=readinessGates"`
	// RuntimeClassName refers to a RuntimeClass object in the node.k8s.io group, which should be used
	// to run this pod.  If no RuntimeClass resource matches the named class, the pod will not be run.
	// If unset or empty, the "legacy" RuntimeClass will be used, which is an implicit class with an
	// empty definition that uses the default runtime handler.
	// More info: https://git.k8s.io/enhancements/keps/sig-node/585-runtime-class
	// +optional
	RuntimeClassName *string `json:"runtimeClassName,omitempty" protobuf:"bytes,29,opt,name=runtimeClassName"`
	// EnableServiceLinks indicates whether information about services should be injected into pod's
	// environment variables, matching the syntax of Docker links.
	// Optional: Defaults to true.
	// +optional
	EnableServiceLinks *bool `json:"enableServiceLinks,omitempty" protobuf:"varint,30,opt,name=enableServiceLinks"`
	// PreemptionPolicy is the Policy for preempting pods with lower priority.
	// One of Never, PreemptLowerPriority.
	// Defaults to PreemptLowerPriority if unset.
	// +optional
	PreemptionPolicy *PreemptionPolicy `json:"preemptionPolicy,omitempty" protobuf:"bytes,31,opt,name=preemptionPolicy"`
	// Overhead represents the resource overhead associated with running a pod for a given RuntimeClass.
	// This field will be autopopulated at admission time by the RuntimeClass admission controller. If
	// the RuntimeClass admission controller is enabled, overhead must not be set in Pod create requests.
	// The RuntimeClass admission controller will reject Pod create requests which have the overhead already
	// set. If RuntimeClass is configured and selected in the PodSpec, Overhead will be set to the value
	// defined in the corresponding RuntimeClass, otherwise it will remain unset and treated as zero.
	// More info: https://git.k8s.io/enhancements/keps/sig-node/688-pod-overhead/README.md
	// +optional
	Overhead ResourceList `json:"overhead,omitempty" protobuf:"bytes,32,opt,name=overhead"`
	// TopologySpreadConstraints describes how a group of pods ought to spread across topology
	// domains. Scheduler will schedule pods in a way which abides by the constraints.
	// All topologySpreadConstraints are ANDed.
	// +optional
	// +patchMergeKey=topologyKey
	// +patchStrategy=merge
	// +listType=map
	// +listMapKey=topologyKey
	// +listMapKey=whenUnsatisfiable
	TopologySpreadConstraints []TopologySpreadConstraint `json:"topologySpreadConstraints,omitempty" patchStrategy:"merge" patchMergeKey:"topologyKey" protobuf:"bytes,33,opt,name=topologySpreadConstraints"`
	// If true the pod's hostname will be configured as the pod's FQDN, rather than the leaf name (the default).
	// In Linux containers, this means setting the FQDN in the hostname field of the kernel (the nodename field of struct utsname).
	// In Windows containers, this means setting the registry value of hostname for the registry key HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters to FQDN.
	// If a pod does not have FQDN, this has no effect.
	// Default to false.
	// +optional
	SetHostnameAsFQDN *bool `json:"setHostnameAsFQDN,omitempty" protobuf:"varint,35,opt,name=setHostnameAsFQDN"`
	// Specifies the OS of the containers in the pod.
	// Some pod and container fields are restricted if this is set.
	//
	// If the OS field is set to linux, the following fields must be unset:
	// -securityContext.windowsOptions
	//
	// If the OS field is set to windows, following fields must be unset:
	// - spec.hostPID
	// - spec.hostIPC
	// - spec.hostUsers
	// - spec.securityContext.appArmorProfile
	// - spec.securityContext.seLinuxOptions
	// - spec.securityContext.seccompProfile
	// - spec.securityContext.fsGroup
	// - spec.securityContext.fsGroupChangePolicy
	// - spec.securityContext.sysctls
	// - spec.shareProcessNamespace
	// - spec.securityContext.runAsUser
	// - spec.securityContext.runAsGroup
	// - spec.securityContext.supplementalGroups
	// - spec.securityContext.supplementalGroupsPolicy
	// - spec.containers[*].securityContext.appArmorProfile
	// - spec.containers[*].securityContext.seLinuxOptions
	// - spec.containers[*].securityContext.seccompProfile
	// - spec.containers[*].securityContext.capabilities
	// - spec.containers[*].securityContext.readOnlyRootFilesystem
	// - spec.containers[*].securityContext.privileged
	// - spec.containers[*].securityContext.allowPrivilegeEscalation
	// - spec.containers[*].securityContext.procMount
	// - spec.containers[*].securityContext.runAsUser
	// - spec.containers[*].securityContext.runAsGroup
	// +optional
	OS *PodOS `json:"os,omitempty" protobuf:"bytes,36,opt,name=os"`

	// Use the host's user namespace.
	// Optional: Default to true.
	// If set to true or not present, the pod will be run in the host user namespace, useful
	// for when the pod needs a feature only available to the host user namespace, such as
	// loading a kernel module with CAP_SYS_MODULE.
	// When set to false, a new userns is created for the pod. Setting false is useful for
	// mitigating container breakout vulnerabilities even allowing users to run their
	// containers as root without actually having root privileges on the host.
	// This field is alpha-level and is only honored by servers that enable the UserNamespacesSupport feature.
	// +k8s:conversion-gen=false
	// +optional
	HostUsers *bool `json:"hostUsers,omitempty" protobuf:"bytes,37,opt,name=hostUsers"`

	// SchedulingGates is an opaque list of values that if specified will block scheduling the pod.
	// If schedulingGates is not empty, the pod will stay in the SchedulingGated state and the
	// scheduler will not attempt to schedule the pod.
	//
	// SchedulingGates can only be set at pod creation time, and be removed only afterwards.
	//
	// +patchMergeKey=name
	// +patchStrategy=merge
	// +listType=map
	// +listMapKey=name
	// +optional
	SchedulingGates []PodSchedulingGate `json:"schedulingGates,omitempty" patchStrategy:"merge" patchMergeKey:"name" protobuf:"bytes,38,opt,name=schedulingGates"`
	// ResourceClaims defines which ResourceClaims must be allocated
	// and reserved before the Pod is allowed to start. The resources
	// will be made available to those containers which consume them
	// by name.
	//
	// This is an alpha field and requires enabling the
	// DynamicResourceAllocation feature gate.
	//
	// This field is immutable.
	//
	// +patchMergeKey=name
	// +patchStrategy=merge,retainKeys
	// +listType=map
	// +listMapKey=name
	// +featureGate=DynamicResourceAllocation
	// +optional
	ResourceClaims []PodResourceClaim `json:"resourceClaims,omitempty" patchStrategy:"merge,retainKeys" patchMergeKey:"name" protobuf:"bytes,39,rep,name=resourceClaims"`
	// Resources is the total amount of CPU and Memory resources required by all
	// containers in the pod. It supports specifying Requests and Limits for
	// "cpu" and "memory" resource names only. ResourceClaims are not supported.
	//
	// This field enables fine-grained control over resource allocation for the
	// entire pod, allowing resource sharing among containers in a pod.
	// TODO: For beta graduation, expand this comment with a detailed explanation.
	//
	// This is an alpha field and requires enabling the PodLevelResources feature
	// gate.
	//
	// +featureGate=PodLevelResources
	// +optional
	Resources *ResourceRequirements `json:"resources,omitempty" protobuf:"bytes,40,opt,name=resources"`
}

PodStatus 结构体

PodStatus 的定义在同一个文件中:


// PodStatus represents information about the status of a pod. Status may trail the actual
// state of a system, especially if the node that hosts the pod cannot contact the control
// plane.
type PodStatus struct {
	// If set, this represents the .metadata.generation that the pod status was set based upon.
	// This is an alpha field. Enable PodObservedGenerationTracking to be able to use this field.
	// +featureGate=PodObservedGenerationTracking
	// +optional
	ObservedGeneration int64 `json:"observedGeneration,omitempty" protobuf:"varint,17,opt,name=observedGeneration"`
	// The phase of a Pod is a simple, high-level summary of where the Pod is in its lifecycle.
	// The conditions array, the reason and message fields, and the individual container status
	// arrays contain more detail about the pod's status.
	// There are five possible phase values:
	//
	// Pending: The pod has been accepted by the Kubernetes system, but one or more of the
	// container images has not been created. This includes time before being scheduled as
	// well as time spent downloading images over the network, which could take a while.
	// Running: The pod has been bound to a node, and all of the containers have been created.
	// At least one container is still running, or is in the process of starting or restarting.
	// Succeeded: All containers in the pod have terminated in success, and will not be restarted.
	// Failed: All containers in the pod have terminated, and at least one container has
	// terminated in failure. The container either exited with non-zero status or was terminated
	// by the system.
	// Unknown: For some reason the state of the pod could not be obtained, typically due to an
	// error in communicating with the host of the pod.
	//
	// More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-phase
	// +optional
	Phase PodPhase `json:"phase,omitempty" protobuf:"bytes,1,opt,name=phase,casttype=PodPhase"`
	// Current service state of pod.
	// More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-conditions
	// +optional
	// +patchMergeKey=type
	// +patchStrategy=merge
	// +listType=map
	// +listMapKey=type
	Conditions []PodCondition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,2,rep,name=conditions"`
	// A human readable message indicating details about why the pod is in this condition.
	// +optional
	Message string `json:"message,omitempty" protobuf:"bytes,3,opt,name=message"`
	// A brief CamelCase message indicating details about why the pod is in this state.
	// e.g. 'Evicted'
	// +optional
	Reason string `json:"reason,omitempty" protobuf:"bytes,4,opt,name=reason"`
	// nominatedNodeName is set only when this pod preempts other pods on the node, but it cannot be
	// scheduled right away as preemption victims receive their graceful termination periods.
	// This field does not guarantee that the pod will be scheduled on this node. Scheduler may decide
	// to place the pod elsewhere if other nodes become available sooner. Scheduler may also decide to
	// give the resources on this node to a higher priority pod that is created after preemption.
	// As a result, this field may be different than PodSpec.nodeName when the pod is
	// scheduled.
	// +optional
	NominatedNodeName string `json:"nominatedNodeName,omitempty" protobuf:"bytes,11,opt,name=nominatedNodeName"`

	// hostIP holds the IP address of the host to which the pod is assigned. Empty if the pod has not started yet.
	// A pod can be assigned to a node that has a problem in kubelet which in turns mean that HostIP will
	// not be updated even if there is a node is assigned to pod
	// +optional
	HostIP string `json:"hostIP,omitempty" protobuf:"bytes,5,opt,name=hostIP"`

	// hostIPs holds the IP addresses allocated to the host. If this field is specified, the first entry must
	// match the hostIP field. This list is empty if the pod has not started yet.
	// A pod can be assigned to a node that has a problem in kubelet which in turns means that HostIPs will
	// not be updated even if there is a node is assigned to this pod.
	// +optional
	// +patchStrategy=merge
	// +patchMergeKey=ip
	// +listType=atomic
	HostIPs []HostIP `json:"hostIPs,omitempty" protobuf:"bytes,16,rep,name=hostIPs" patchStrategy:"merge" patchMergeKey:"ip"`

	// podIP address allocated to the pod. Routable at least within the cluster.
	// Empty if not yet allocated.
	// +optional
	PodIP string `json:"podIP,omitempty" protobuf:"bytes,6,opt,name=podIP"`

	// podIPs holds the IP addresses allocated to the pod. If this field is specified, the 0th entry must
	// match the podIP field. Pods may be allocated at most 1 value for each of IPv4 and IPv6. This list
	// is empty if no IPs have been allocated yet.
	// +optional
	// +patchStrategy=merge
	// +patchMergeKey=ip
	// +listType=map
	// +listMapKey=ip
	PodIPs []PodIP `json:"podIPs,omitempty" protobuf:"bytes,12,rep,name=podIPs" patchStrategy:"merge" patchMergeKey:"ip"`

	// RFC 3339 date and time at which the object was acknowledged by the Kubelet.
	// This is before the Kubelet pulled the container image(s) for the pod.
	// +optional
	StartTime *metav1.Time `json:"startTime,omitempty" protobuf:"bytes,7,opt,name=startTime"`

	// Statuses of init containers in this pod. The most recent successful non-restartable
	// init container will have ready = true, the most recently started container will have
	// startTime set.
	// Each init container in the pod should have at most one status in this list,
	// and all statuses should be for containers in the pod.
	// However this is not enforced.
	// If a status for a non-existent container is present in the list, or the list has duplicate names,
	// the behavior of various Kubernetes components is not defined and those statuses might be
	// ignored.
	// More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-and-container-status
	// +listType=atomic
	InitContainerStatuses []ContainerStatus `json:"initContainerStatuses,omitempty" protobuf:"bytes,10,rep,name=initContainerStatuses"`

	// Statuses of containers in this pod.
	// Each container in the pod should have at most one status in this list,
	// and all statuses should be for containers in the pod.
	// However this is not enforced.
	// If a status for a non-existent container is present in the list, or the list has duplicate names,
	// the behavior of various Kubernetes components is not defined and those statuses might be
	// ignored.
	// More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-and-container-status
	// +optional
	// +listType=atomic
	ContainerStatuses []ContainerStatus `json:"containerStatuses,omitempty" protobuf:"bytes,8,rep,name=containerStatuses"`

	// The Quality of Service (QOS) classification assigned to the pod based on resource requirements
	// See PodQOSClass type for available QOS classes
	// More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/#quality-of-service-classes
	// +optional
	QOSClass PodQOSClass `json:"qosClass,omitempty" protobuf:"bytes,9,rep,name=qosClass"`

	// Statuses for any ephemeral containers that have run in this pod.
	// Each ephemeral container in the pod should have at most one status in this list,
	// and all statuses should be for containers in the pod.
	// However this is not enforced.
	// If a status for a non-existent container is present in the list, or the list has duplicate names,
	// the behavior of various Kubernetes components is not defined and those statuses might be
	// ignored.
	// More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-and-container-status
	// +optional
	// +listType=atomic
	EphemeralContainerStatuses []ContainerStatus `json:"ephemeralContainerStatuses,omitempty" protobuf:"bytes,13,rep,name=ephemeralContainerStatuses"`

	// Status of resources resize desired for pod's containers.
	// It is empty if no resources resize is pending.
	// Any changes to container resources will automatically set this to "Proposed"
	// Deprecated: Resize status is moved to two pod conditions PodResizePending and PodResizeInProgress.
	// PodResizePending will track states where the spec has been resized, but the Kubelet has not yet allocated the resources.
	// PodResizeInProgress will track in-progress resizes, and should be present whenever allocated resources != acknowledged resources.
	// +featureGate=InPlacePodVerticalScaling
	// +optional
	Resize PodResizeStatus `json:"resize,omitempty" protobuf:"bytes,14,opt,name=resize,casttype=PodResizeStatus"`

	// Status of resource claims.
	// +patchMergeKey=name
	// +patchStrategy=merge,retainKeys
	// +listType=map
	// +listMapKey=name
	// +featureGate=DynamicResourceAllocation
	// +optional
	ResourceClaimStatuses []PodResourceClaimStatus `json:"resourceClaimStatuses,omitempty" patchStrategy:"merge,retainKeys" patchMergeKey:"name" protobuf:"bytes,15,rep,name=resourceClaimStatuses"`
}

reference 文档

pod 的 reference 文档:

https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/

Source: ContainerType

Mon, 31 Mar 2025 00:00:00 +0000

ContainerType 定义

ContainerType 类型定义，有3个类型：

// ContainerType signifies container type
type ContainerType int

const (
	// Containers is for normal containers
	Containers ContainerType = 1 << iota
	// InitContainers is for init containers
	InitContainers
	// EphemeralContainers is for ephemeral containers
	EphemeralContainers
)

// AllContainers specifies that all containers be visited
const AllContainers ContainerType = (InitContainers | Containers | EphemeralContainers)

AllFeatureEnabledContainers() 方法

AllFeatureEnabledContainers() 方法返回一个 ContainerType mask，其中包括所有容器类型，但受 feature gate 保护的容器类型除外。

// AllContainers specifies that all containers be visited
const AllContainers ContainerType = (InitContainers | Containers | EphemeralContainers)

// AllFeatureEnabledContainers returns a ContainerType mask which includes all container
// types except for the ones guarded by feature gate.
func AllFeatureEnabledContainers() ContainerType {
	return AllContainers
}

备注：没有什么 feature gate 啊

Concepts: Kubernetes API

Mon, 01 Feb 2021 00:00:00 +0000

https://kubernetes.io/zh-cn/docs/concepts/overview/kubernetes-api/

Kubernetes 控制面的核心是 API 服务器。 API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和集群外部组件相互通信。

Kubernetes API 使你可以查询和操纵 Kubernetes API 中对象（例如：Pod、Namespace、ConfigMap 和 Event）的状态。

大部分操作都可以通过 kubectl 命令行接口或类似 kubeadm 这类命令行工具来执行，这些工具在背后也是调用 API。不过，你也可以使用 REST 调用来访问这些 API。

OpenAPI 规范

OpenAPI V2

Kubernetes API 服务器通过 /openapi/v2 端点提供聚合的 OpenAPI v2 规范。

Kubernetes 为 API 实现了一种基于 Protobuf 的序列化格式，主要用于集群内部通信。

OpenAPI V3

特性状态： Kubernetes v1.24 [beta]

Kubernetes v1.25 提供将其 API 以 OpenAPI v3 形式发布的 beta 支持；这一功能特性处于 beta 状态，默认被开启。

API 变更

Kubernetes 对维护达到正式发布（GA）阶段的官方 API 的兼容性有着很强的承诺，通常这一 API 版本为 v1。

API 扩展

有两种途径来扩展 Kubernetes API：

你可以使用自定义资源来以声明式方式定义 API 服务器如何提供你所选择的资源 API。
你也可以选择实现自己的聚合层来扩展 Kubernetes API。

Concepts: Ingress

Mon, 01 Feb 2021 00:00:00 +0000

https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/

Ingress 是对集群中服务的外部访问进行管理的 API 对象

术语

节点（Node）: Kubernetes 集群中的一台工作机器，是集群的一部分。
集群（Cluster）: 一组运行由 Kubernetes 管理的容器化应用程序的节点。在此示例和在大多数常见的 Kubernetes 部署环境中，集群中的节点都不在公共网络中。
边缘路由器（Edge Router）: 在集群中强制执行防火墙策略的路由器。可以是由云提供商管理的网关，也可以是物理硬件。
集群网络（Cluster Network）: 一组逻辑的或物理的连接，根据 Kubernetes 网络模型在集群内实现通信。
服务（Service）：Kubernetes 服务（Service），使用标签选择器（selectors）辨认一组 Pod。除非另有说明，否则假定服务只具有在集群网络中可路由的虚拟 IP。

Ingress 是什么？

Ingress 暴露从集群外部到集群内服务的 HTTP 和 HTTPS 路由。流量路由由 Ingress 资源上定义的规则控制。

下面是一个将所有流量都发送到同一 Service 的简单 Ingress 示例：

Ingress 不会公开任意端口或协议。将 HTTP 和 HTTPS 以外的服务公开到 Internet 时，通常使用 Service.Type=NodePort 或 Service.Type=LoadBalancer 类型的 Service。

Client: [第二章]Kubernetes API操作

Mon, 01 Feb 2021 00:00:00 +0000

上一章介绍了 Kubernetes API 遵循 REST 原则，使用户能够操作资源。

在本章中，你将学习如何通过直接发出 HTTP 请求来执行各种操作。在你的日常工作中，你可能不需要直接与HTTP层进行交互，但了解API在这个层面上的工作原理是很重要的，这样你就能理解如何用更高层次的库更容易地使用它。

检查请求

在开始编写你自己的HTTP请求之前，你可以用 kubectl 检查哪些请求是在执行kubectl命令时使用的。这可以通过使用大于或等于6的 verbose 标志-v来实现。表2-1显示了在每个级别上显示的信息。

例如，如果你想知道在获取所有命名空间的pod时被调用的URL，你可以使用以下命令：

$ kubectl get pods --all-namespaces -v6

loader.go:372] Config loaded from file:  /home/user/.kube/config
round_trippers.go:553] GET https://192.168.1.194:6443/api/v1/pods?limit=500 200 OK in 745 milliseconds

在该命令的输出中，你可以看到使用的路径是 /api/v1/pods。或者，在获取特定命名空间的pod时，你可以看到使用的路径是 /api/v1/namespaces/default/pods

$ kubectl get pods --namespace default -v6

loader.go:372] Config loaded from file:  /home/user/.kube/config
round_trippers.go:553] GET https://192.168.1.194:6443/api/v1/namespaces/default/pods?limit=500 200 OK in 138 milliseconds

动词级别

Level	Method and URL	Request timing	Events timing	Request headers	Response status	Response headers	Curl cmd	Body length
-v 6	yes	yes	–	–	–	–	–	0
-v 7	yes	–	–	yes	yes	–	–	0
-v 8	yes	–	–	yes	yes	yes	-	≤ 1024
-v 9	yes	yes	yes	–	–	yes	yes	≤ 10240
-v 10	yes	yes	yes	–	–	yes	yes	∞

提出请求

本节研究了你可以对Kubernetes资源进行的所有操作。

使用 kubectl 作为代理

你必须经过认证才能向集群的 Kubernetes API 发出请求，除非你的集群接受未经认证的请求，但这是不可能的。

运行认证的HTTP请求的方法是使用kubectl作为代理，使其处理认证。为此，可以使用 kubectl proxy命令：

kubectl proxy

开始在 127.0.0.1:8001 上提供服务

在一个新的终端上，你现在可以运行你的 HTTP 请求，不需要任何认证。接下来，定义一个HOST变量来访问代理：

HOST=http://127.0.0.1:8001

创建资源

你可以通过首先创建描述该资源的Kubernetes清单来创建一个新的资源–例如，要创建一个Pod，你可以写：

cat > pod.yaml <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
EOF

然后，你需要将资源描述传递到POST请求的正文中（注意，-X POST标志可以省略，因为使用的是 -data-binary 标志）。例如，要创建一个pod资源，请使用：

curl $HOST/api/v1/namespaces/project1/pods -H "Content-Type: application/yaml" --data-binary @pod.yaml

这等同于运行kubectl命令：

kubectl create --namespace project1 -f pod.yaml -o json

请注意，命名空间在 pod.yaml 文件中没有被指出。如果你添加它，你必须在 YAML 文件和路径中指定相同的命名空间，否则你会得到一个错误–即提供的对象的命名空间与请求中发送的命名空间不匹配。

获取资源的信息

你可以使用GET请求来获取特定资源的信息，并在路径中传递其名称作为参数（如果是命名空间的资源，还要传递其命名空间）。在这个例子中，你将请求project1命名空间中的nginx的信息：

curl -X GET $HOST/api/v1/namespaces/project1/pods/nginx

这将返回JSON格式的资源信息，使用与该资源相关的种类作为结构；在这个例子中，它是一个Pod种类。这等同于运行kubectl命令：

kubectl get pods --namespace project1 nginx -o json

获取资源列表

对于命名空间的资源，你可以获得整个集群或特定命名空间的资源列表。对于非命名空间的资源，你可以获得资源的列表。在任何情况下，你将使用GET请求。

集群范围

要获得集群范围内的资源列表，对于带命名空间的或不带命名空间的资源；例如，对于pod资源，使用以下方法：

curl $HOST/api/v1/pods

这将返回所有命名空间的pod列表的信息，使用PodList种类。这等同于运行kubectl命令：

kubectl get pods --all-namespaces -o json

在特定的命名空间中

要获得特定命名空间中的资源列表，你需要在路径中指明命名空间；例如，对于pod资源，可以这样使用：

curl $HOST/api/v1/namespaces/project1/pods

这将返回project1命名空间中的pod列表信息，使用PodList种类。这等同于运行kubectl命令：

kubectl get pods --namespace project1 -o json

筛选列表的结果

当运行一个 list 请求时，你会得到这类资源的完整列表，在指定的命名空间或集群范围内，取决于你的请求。

你可能想过滤这个结果。在Kubernetes中过滤资源最常见的方法是使用标签 label。为此，资源需要有定义的标签；然后，在列表请求中，你可以定义一些标签选择器。也可以通过使用字段选择器，根据一组有限的字段来过滤资源。

使用标签选择器

所有 Kubernetes 资源都可以定义标签。例如，在创建pod时，你可以用kubectl定义一些标签：

kubectl run nginx1 --image nginx --labels mylabel=foo
kubectl run nginx2 --image nginx --labels mylabel=bar

这导致了带有在资源的元数据部分定义的标签的 pod：

$ kubectl get pods nginx1 -o yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    mylabel: foo
  name: nginx1
[...]
$ kubectl get pods nginx2 -o yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    mylabel: bar
  name: nginx2
[...]

现在，当运行 list 请求时，你可以通过使用 labelSelector 查询参数定义一些标签选择器来过滤这些资源，这个参数可以包含一个逗号分隔的选择器列表。

选择所有定义特定标签的资源，无论其值如何；例如，mylabel标签：
```
curl "$HOST/api/v1/namespaces/default/pods?labelSelector=mylabel"
```
选择所有没有定义特定标签的资源；例如，mylabel标签：
```
curl "$HOST/api/v1/namespaces/default/pods?labelSelector=\!mylabel"
```
注意：

标签名称前的感叹号（！）–使用反斜线字符（\）是因为感叹号是shell的一个特殊字符。

选择所有定义有特定值的标签的资源；例如，mylabel的值是foo：

curl "$HOST/api/v1/namespaces/default/pods?labelSelector=mylabel==foo"

或者

curl "$HOST/api/v1/namespaces/default/pods?labelSelector=mylabel=foo"

选择所有定义标签的资源，其值与特定的标签不同；例如，标签mylabel的值与foo不同：
```
curl "$HOST/api/v1/namespaces/default/pods?labelSelector=mylabel\!=foo"
```
注意：

等号（=）前的感叹号（！）–使用反斜杠字符（\）是因为感叹号是shell的一个特殊字符。
选择所有定义有一组值的标签的资源；例如，具有foo或baz其中一个值的标签mylabel：
```
curl "$HOST/api/v1/namespaces/default/pods?labelSelector=mylabel+in+(foo,baz)"
```
注意:

加号字符（+），它对URL中的空格进行编码。原来的选择器是：mylabel in (foo,baz)。
选择所有定义标签的资源，其值不在一组值中；例如，标签mylabel的值与foo或baz不同：
```
curl "$HOST/api/v1/namespaces/default/pods?labelSelector=mylabel+notin+(foo,baz)"
```
注意:

加号字符（+），它对URL中的空格进行编码。原来的选择器是：mylabel notin (foo,baz)。

你可以用逗号把几个选择器分开来组合。这将充当一个 AND 操作符。例如，要选择所有定义了标签 mylabel 并且标签otherlabel等于bar的资源，你可以使用以下标签选择器：

curl "$HOST/api/v1/namespaces/default/pods?labelSelector=mylabel,otherlabel==bar"

使用字段选择器

你可以使用一组有限的字段来过滤资源。对于所有资源，你可以在 metadata.name 字段上进行过滤；对于所有 namespaced 资源，你可以在metadata.namespace 字段上过滤。

下面是 Kubernetes 1.23的其他可用于过滤的字段列表，具体取决于资源：

core.event:

involvedObject.apiVersion
involvedObject.fieldPath
involvedObject.kind
involvedObject.name
involvedObject.namespace
involvedObject.resourceVersion
involvedObject.uid
reason
reportingComponent
source
type

core.namespace:

status.phase

core.node:

spec.unschedulable

core.pod:

spec.nodeName
spec.restartPolicy
spec.schedulerName
spec.serviceAccountName
status.nominatedNodeName
status.phase
status.podIP

core.replicationcontroller:

status.replicas

core.secret:

type

apps.replicaset:

status.replicas

batch.job:

status.successful

certificates.certificatesigningrequest:

spec.signerName

现在，当运行 list 请求时，你可以通过使用 fieldSelector 参数来指示一些字段选择器来过滤这些资源，该参数可以包含一个逗号分隔的选择器列表。

选择某个字段有特定值的所有资源；例如，字段 status.phase 的值为Running：

curl "$HOST/api/v1/namespaces/default/pods?fieldSelector=status.phase==Running"

或者

curl "$HOST/api/v1/namespaces/default/pods?fieldSelector=status.phase=Running"

选择某个字段的值与特定字段不同的所有资源；例如，字段 status.phase 的值与 Running 不同：
```
curl "$HOST/api/v1/namespaces/default/pods?fieldSelector=status.phase\!=Running"
```

你可以用逗号把几个选择器分开来组合。这将充当一个AND运算符。例如，要选择所有 phase 等于 “运行 “且重启策略不是 “总是 “的 pod，你可以使用这个字段选择器：

curl "$HOST/api/v1/namespaces/default/pods?fieldSelector=status.phase==Running,spec.restartPolicy\!=Always"

删除资源

要删除资源，你需要在路径中指定它的名字（和带有命名空间的资源的命名空间）并使用DELETE请求。例如，要删除pod，使用下面的方法：

curl -X DELETE "$HOST/api/v1/namespaces/project1/pods/nginx"

这将以 JSON 格式返回被删除资源的信息，使用与该资源相关的种类–本例是Pod kind。

这相当于运行kubectl命令（除了你不能得到关于被删除资源的信息，只能通过-o name标志得到它的名字）：

kubectl delete pods --namespace project1 nginx

删除资源的集合

也可以使用DELETE请求删除特定命名空间中的特定资源集合；对于命名空间的资源，在路径中指明命名空间：

curl -X DELETE "$HOST/api/v1/namespaces/project1/pods"

这将以JSON格式返回被删除资源的信息，使用与资源相关的List种类；在这个例子中，PodList种类。

这相当于运行kubectl命令（除了不能获得被删除资源的信息，只能通过-o name标志获得其名称）：

kubectl delete pods --namespace project1 --all

注意

不可能像使用kubectl命令那样，在一次请求中从所有命名空间中删除所有特定种类的资源：kubectl delete pods –all-namespaces –all。

更新资源

通过使用PUT请求并在路径中指定名称（和带有命名空间的资源的命名空间）以及在请求正文中指定新的资源信息，可以替换关于特定资源的完整信息。

为了说明这一点，你可以首先定义一个新的 deployment，使用以下命令：

cat > deploy.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
EOF

然后，你可以用以下方法在集群中创建这个部署：

curl "$HOST/apis/apps/v1/namespaces/project1/deployments" -H "Content-Type: application/yaml" --data-binary @deploy.yaml

接下来，你可以为部署创建一个更新的清单；例如，通过以下命令更新容器的镜像（这将把镜像名称nginx替换为nginx:latest）：

cat deploy.yaml | sed 's/image: nginx/image: nginx:latest/' > deploy2.yaml

最后，你可以使用以下请求来更新部署到集群中：

curl -X PUT "$HOST/apis/apps/v1/namespaces/project1/deployments/nginx" -H "Content-Type: application/yaml" --data-binary @deploy2.yaml

这等同于运行kubectl命令：

kubectl replace --namespace project1  -f deploy2.yaml -o json

更新资源时的冲突管理

当用以前的技术更新一个资源时，如果另一个参与者在你创建它和你更新它之间对资源进行了修改，那么在你更新资源时，其他参与者所做的修改将会丢失。

为了避免这种冲突的风险，你可以先读取资源信息（使用GET请求），在资源的元数据中找到 resourceVersion 字段的值，然后在你要更新的资源的规格中指出这个resourceVersion。

通过发送带有该 resourceVersion 的PUT请求，API 服务器将比较所收到的资源和当前资源的 resourceVersion 值。如果数值不同（因为另一个参与者在此期间修改了该资源），API服务器将回复错误：操作无法在[…]上完成：该对象已被修改；请将您的修改应用到最新的版本上并重试。

为了说明问题，让我们来创建部署（如果你已经从上一节创建了它，请确保在这样做之前删除它）：

curl "$HOST/apis/apps/v1/namespaces/project1/deployments" -H "Content-Type: application/yaml" --data-binary @deploy.yaml

你将收到一个响应，表明你所创建的资源的 resourceVersion；在这个例子中，它是668867：

{
  "kind": "Deployment",
  "apiVersion": "apps/v1",
  "metadata": {
    "name": "nginx",
    "namespace": "project1",
    "uid": "99d3a1eb-176c-40de-89ec-74313169fe60",
    "resourceVersion": "668867",
    "generation": 1,
  [...]
}

在等待几秒钟后，你可以执行一个GET请求来查找最新的版本，你会收到以下响应：

curl "$HOST/apis/apps/v1/namespaces/project1/deployments/nginx"

{
  "kind": "Deployment",
  "apiVersion": "apps/v1",
  "metadata": {
    "name": "nginx",
    "namespace": "project1",
    "uid": "99d3a1eb-176c-40de-89ec-74313169fe60",
    "resourceVersion": "668908",
    "generation": 1,
  [...]
}

你可以看到 resourceVersion 已经被递增，现在是668908。发生这种情况是因为部署控制器已经自行更新了资源。

现在，如果你把第一次收到的版本添加到YAML清单中，并试图更新部署，你会得到一个错误，表明已经检测到冲突：

cat > deploy2.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  resourceVersion: "668867"
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
EOF

curl -X PUT "$HOST/apis/apps/v1/namespaces/project1/deployments/nginx" -H "Content-Type: application/yaml" --data-binary @deploy2.yaml

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
  },
  "status": "Failure",
  "message": "Operation cannot be fulfilled on deployments.apps \"nginx\": the object has been modified; please apply your changes to the latest version and try again",
  "reason": "Conflict",
  "details": {
    "name": "nginx",
    "group": "apps",
    "kind": "deployments"
  },
  "code": 409
}

现在，如果你使用以下命令用最新的资源版本更新YAML清单，并再次运行PUT命令，操作将成功：

$ sed -i 's/668867/668908/' deploy2.yaml
$ curl -X PUT
 $HOST/apis/apps/v1/namespaces/project1/deployments/nginx
 -H "Content-Type: application/yaml"
 --data-binary @deploy2.yaml
{
  "kind": "Deployment",
  "apiVersion": "apps/v1",
  "metadata": {
    "name": "nginx",
    "namespace": "project1",
    "uid": "99d3a1eb-176c-40de-89ec-74313169fe60",
    "resourceVersion": "671623",
    "generation": 2,
[...]
}

使用 Strategic Merge Patch 来更新资源

当修改资源时，与其发送完整的描述，不如通过使用补丁只发送你想修改的部分。

这可以通过使用带有 application/strategic-merge-patch+json content-type 的 PATCH 请求来实现，并在路径中指定名称（和带有命名空间的资源的命名空间），在请求的正文中指定补丁信息。

补丁信息是 YAML 清单的提取物，其中只包含你想更新的字段。这样做，你在路径中指定的字段将被更新，而补丁中未指定的字段将保持不动。

为了说明这一点，您可以先用以下方式创建一个包含补丁信息的文件：

$ cat > deploy-patch.json <<EOF
{
  "spec":{
    "template":{
      "spec":{
        "containers":[{
          "name":"nginx",
          "image":"nginx:alpine"
        }]
}}}}
EOF

然后，你可以通过以下请求将这个补丁应用于资源：

请注意具体使用的 Content-Type 头为 pplication/strategic-merge-patch+json 。

$ curl -X PATCH
 $HOST/apis/apps/v1/namespaces/project1/deployments/nginx
 -H
 "Content-Type: application/strategic-merge-patch+json"
 --data-binary @deploy-patch.json

这等同于运行 kubectl 命令：

$ kubectl patch deployment nginx --namespace project1
    --patch-file deploy-patch.json
    --type=strategic
    -o json

当字段是单一的值（要么是像字符串这样的简单值，要么是一个有几个字段的对象），补丁的值会取代现有的值。

注意:

如果字段在补丁中不存在，原始值将不会被删除，而是保持不动。你可以为字段指定 null 值，以便从结果中删除它。

修补数组字段

当字段包含数组的值时，其行为与单个值的行为不同。

默认行为取决于 Kubernetes API 规范中为该字段定义的补丁策略。例如，你可以在图2-1中看到，container 结构体的 env 字段在键名上的补丁策略是 Merge 。补丁策略的另一个可能值是 Replace。

当字段的补丁策略是 Replace（替换）时，结果数组是包含在补丁中的数组，而原始数组中的值不被考虑。

当字段的补丁策略是在特定的键上合并时，原始数组和补丁数组将被合并。补丁数组中包含的元素，但不存在于原始数组中，将被添加到结果中，原始数组和补丁数组中存在的元素将获得补丁元素的值（如果元素的键值相同，则原始数组和补丁数组中的元素是相同的）。

注意

原数组中存在的元素，但在补丁中不存在，将保持不动。

为了说明问题，考虑现有的部署，其中有一个定义了这些环境变量的容器，以及一个定义了这些值的补丁：

**Original       Patch**

env:         env:

\- name: key1    - name: key1

 value: value1    value: value1bis

\- name: key2    - name: key3

 value: value2    value: value3

通过将该补丁应用于现有的部署，产生的环境变量列表将是以下内容：

Result for Merge strategy
env:
- name: key1
  value: value1bis
- name: key2
  value: value2
- name: key3
  value: value3

替换指令

你可以对对象或数组使用替换指令。当对对象使用时，原始对象将被替换成补丁对象。这意味着不在补丁中的字段这次不会出现在结果中；而且这个对象的数组将与补丁中的数组完全相同，不会发生合并操作。

要为对象声明这个指令，你需要为该对象添加一个字段 $patch，值为 replace。例如，下面的补丁将用一个只包含 runAsNonRoot 字段的 securityContext 来替换 nginx 容器的 securityContext：

{
  "spec":{
    "template":{
      "spec":{
        "containers":[{
          "name":"nginx",
          "securityContext": {
            "$patch": "replace",
            "runAsNonRoot": false
}}]}}}}

当与数组一起使用时，原始数组将被补丁数组所取代。

要为数组声明这个指令，你需要为这个数组添加一个对象，其中有一个值为替换的单字段 $patch。例如，下面的补丁将把容器 nginx 的环境变量设置为单一变量key1，而不考虑之前定义的变量数量。

{
  "spec":{
    "template":{
      "spec":{
        "containers":[{
          "name":"nginx",
          "env": [
            { "$patch": "replace"},
            { "name": "key1", "value": "value1" }
          ]
}]}}}}

删除指令

你可以对对象或数组中的对象元素使用删除指令。对对象使用这个指令，就像把这个对象的值声明为空。例如，这个补丁将从容器 nginx 中删除字段securityContext：

{
  "spec":{
    "template":{
      "spec":{
        "containers":[{
          "name":"nginx",
          "securityContext": {
            "$patch": "delete"
          }
}]}}}}

要从列表中删除一个元素，你需要将指令添加到你要删除的元素中。你需要指出键字段（为 Merge 补丁策略指出的键）。例如，你可以用这个补丁来删除名为key1的环境变量：

{
  "spec":{
    "template":{
      "spec":{
        "containers":[
        {
          "name":"nginx",
          "env": [{
              "name": "key1",
              "$patch": "delete"
          }]
}]}}}}

deleteFromPrimitiveList指令

delete 指令只适用于从数组中删除对象。你可以使用 deleteFromPrimitiveList 指令，通过在包含数组的字段名前加上 $deleteFromPrimitiveList/ 来删除数组中的原始元素。例如，要从 nginx 容器的 args 列表中删除 -debug 参数，可以使用以下补丁：

{
  "spec":{
    "template":{
      "spec":{
        "containers":[
        {
          "name":"nginx",
          "$deleteFromPrimitiveList/args": [
            "--debug"
          ]
}]}}}}

注意

这个指令对于 Kubernetes 1.24 和更早的版本不能正常工作，因为它只保留指定的值，而不是只保留其他值。

setElementOrder指令

setElementOrder 指令可以用来将数组中的元素排序成不同的顺序，方法是在包含要排序的数组的字段名前加上 $setElementOrder/。例如，要重新排序部署的 initContainers，可以使用这个补丁：

{
  "spec":{
    "template":{
      "spec":{
        "$setElementOrder/initContainers":[
          { "name": "init2"},
          { "name": "init1"}
        ]}}}}

应用服务器端的资源

正如你在前面的章节中所看到的，你可以更新资源，但在发生冲突的情况下，你需要编写特定的指令来表明如何解决冲突。Kubernetes API 在 Kubernetes 1.16中引入了服务器端应用的Beta功能，从 Kubernetes 1.22开始，它已经成为一个稳定的功能。

服务器端 Apply 操作和 Update 命令一样，不同的是，即使资源在集群中不存在，也可以使用这个命令，而且执行命令时必须提供一个字段管理器。

服务器端应用操作可以使用 PATCH 请求来执行，其内容类型为 application/apply-patch+yaml，并在路径中指定名称（和命名空间的资源），在请求的正文中指定补丁信息。

Kubernetes API 将在资源的一个专用字段（.metadata.managedFields）中保存该资源中完成的应用操作列表。

对于每个保存的 Apply 操作，它所设置的每个字段都被操作期间提供的字段管理器标记为 “owned”。如果 Apply 操作更新了一个由另一个字段管理器拥有的字段，因为之前的 Apply 操作覆盖了这个字段，就会产生冲突。

可以强制执行 Apply 操作，以便用新值建立冲突的字段，并将所有权转移给新的字段管理器。所有权被设置在对象或原始元素中，以及数组的元素中。

例如，字段管理器可以为容器定义一组环境变量，而另一个字段管理器可以为Pod的同一个容器定义一组不同的环境变量。每个字段管理器拥有它的环境变量。如果第一个字段管理器通过删除它的一些环境变量来运行一个新的Apply操作，这些环境变量将从总列表中删除，但另一个字段管理器的环境变量不会受到影响。

为了说明这个例子，你可以为一个部署创建以下YAML清单，该清单为Pod的容器定义了三个环境变量：

# deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        env:
        - name: key1
          value: value1
        - name: key2
          value: value2
        - name: key3
          value: value3

然后，您可以通过使用服务器端应用操作来应用这个清单（注意内容类型头被设置为 application/apply-patch+yaml，查询参数 fieldManager 被设置为manager1）：

$ curl -X PATCH
$HOST/apis/apps/v1/namespaces/project1/deployments/nginx?fieldManager=manager1
 -H
 "Content-Type: application/apply-patch+yaml"
 --data-binary @deploy.yaml

这条命令将创建部署。你可以检查用这个命令创建的部署资源的 .metadata.managedFields（jq被用来获取缩进的JSON形式）：

$ kubectl get deploy nginx -o jsonpath={.metadata.managedFields} | jq
[{
  "apiVersion": "apps/v1",
  "fieldsType": "FieldsV1",
  "fieldsV1": {
    "f:spec": {
      "f:template": {
        "f:spec": {
          "f:containers": {
            "k:{\"name\":\"nginx\"}": {
              ".": {},       ➊
              "f:image": {}, ➋
              "f:name": {}   ➌
              "f:env": {
                "k:{\"name\":\"key1\"}": {
                  ".": {}, "f:name": {}, "f:value": {} ➍
                },
                "k:{\"name\":\"key2\"}": {
                  ".": {}, "f:name": {}, "f:value": {} ➎
                },
                "k:{\"name\":\"key3\"}": {
                  ".": {}, "f:name": {}, "f:value": {} ➏
  }}}}}}}},
  "manager": "manager1",  ➐
  "operation": "Apply",   ➑
  "time": "2022-07-14T16:46:48Z"
},
{
  "apiVersion": "apps/v1",
  "fieldsType": "FieldsV1",
  "fieldsV1": {
    "f:status": {
      "f:availableReplicas": {},
      "f:observedGeneration": {},
      "f:readyReplicas": {},
      "f:replicas": {},
      "f:updatedReplicas": {}
    }
  },
  "manager": "kube-controller-manager", ➒
  "operation": "Update",                ➓
  "subresource": "status",
  "time": "2022-07-14T16:46:52Z"
}]

你可以在managedFields中看到，你的操作被保存为Apply操作，➑，由经理manager1➐；这个管理器拥有名称为nginx ➊的容器元素、字段image ➋、name ➌，以及名称为key1 ➍、key2 ➎、key3 ➏的env元素。

管理者是用于编辑资源的任何程序；例如，kubectl在使用编辑或应用命令时，或管理这些资源的控制器或操作员。你还可以看到，第二个更新➓类型的操作已被保存，并由kube-controller-manager ➒拥有，因为在你创建部署资源时，部署控制器在其状态中设置了一些值。

现在，第二个管理器，manager2，想更新环境变量key2。它可以通过创建以下内容并运行该命令（注意强制查询参数被设置为真）来实现：

TBD.。。。。。

观察资源

Kubernetes API允许你观察资源。这意味着你的请求不会立即终止，而是一个长期运行的请求，它将发送一个JSON流作为响应，当被监视的资源发生变化时将JSON对象添加到流中。JSON流是一系列由新行分隔的JSON对象–例如：

{ "type": "ADDED", "object": ... }
{ "type": "DELETED", "object": ... }

观察资源的请求与用于列出资源的请求一样，只是将 watch 参数作为查询参数添加。例如，要观察 project1 命名空间的pod，你可以发送这个请求：

curl "$HOST/api/v1/namespaces/project1/pods?watch=true"

在 Kubernetes 术语中，流的每个JSON对象被称为 Watch Event ，它将包含两个字段： type 和 object。类型的值可以是ADDED、MODIFIED、DELETED、BOOKMARK 或 ERROR。对于每一种类型，其对象如表2-2所描述。

表2-2每种类型的观察事件的对象描述

Type value	Object description
ADDEDMODIFIED	资源的新状态，使用其 kind（例如，Pod）。
DELETED	该资源在被删除前的状态，使用其 kind（例如，Pod）。
BOOKMARK	resource version，使用它的 kind（例如，Pod），只设置 resourceVersion 字段。在本章的后面，你会看到在哪些情况下会使用这种类型。
ERROR	描述错误的对象。

当这个请求被执行时，你会立即得到一系列的 ADDED JSON 对象，描述在请求时集群中存在的所有资源；最终，当集群中的资源被创建、修改或删除时，会有其他事件发生。这相当于运行 kubectl 命令，不同的是不给类型字段，直接给对象的内容：

kubectl get pods --namespace project1 --watch -o json

在列出资源后进行观察

你可以先运行 list 请求来找到现有资源的列表，然后运行 watch 请求来获得这些资源的修改情况，而不是把请求时存在的资源作为 watch 响应的一部分。这样做有一个风险，即在 list 请求和 watch 请求开始之间可能会发生一些修改，而你并没有得到关于这些修改的通知。

对于这种情况，你可以使用列表请求返回的 resourceVersion 值来指示你想在哪个时间点开始你的观察请求。(注意：你需要将 resourceVersion 获取到 List 结构体中，而不是从一个子项中获取。)

作为例子，你可以首先通过使用命令获得 pod 的列表：

curl "$HOST/api/v1/pods"

{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion": "2433789"
  },
  "items": [ ... ]
}

作为对这第一个请求的响应，你会得到资源版本和在请求时存在于项目领域的资源列表。然后，你可以通过指定这个资源版本来执行 watch 请求：

curl "$HOST/api/v1/namespaces/default/pods?watch=true&resourceVersion=2433789"

因此，你不会立即在响应体中收到描述集群中存在的资源的数据；只有当一些资源被修改、添加或删除时，你才会收到数据。

重启观察请求

观察请求可能会被中断，你可能想在这个过程中从最后收到的修改（或之前的修改）重新启动它。

为此，观察响应中的 DELETE、ADD 或 MODIFIED JSON 对象的每个资源部分都包含 resourceVersion，你可以用它来执行一个新的观察请求，就在指定的修改之后开始。例如，你可以启动一个 watch 请求，在几次修改后就中断了：

$ curl "$HOST/api/v1/namespaces/default/pods?watch=true"
{"type":"ADDED","object":{
  "kind":"Pod","apiVersion":"v1","metadata":{
    "resourceVersion":"2435623", ...}, ...}}
{"type":"ADDED","object":{
  "kind":"Pod","apiVersion":"v1","metadata":{
    "resourceVersion":"2354893", ...}, ...}}
{"type":"MODIFIED","object":{
  "kind":"Pod","apiVersion":"v1","metadata":{
    "resourceVersion":"2436655", ...}, ...}}
{"type":"DELETED","object":{
  "kind":"Pod","apiVersion":"v1","metadata":{
    "resourceVersion":"2436677", ...}, ...}}

然后，你可以从上一次请求的任何时间开始，或从最近一次修改后开始，重新启动 watch 请求：

$ curl "$HOST/api/v1/namespaces/default/pods?watch=true&resourceVersion=2436677"

或者在之前的修改之后开始。这样，你将再次收到最新的修改：

$ curl "$HOST/api/v1/namespaces/default/pods?watch=true&resourceVersion=2436655"
{"type":"DELETED","object":{
  "kind":"Pod","apiVersion":"v1","metadata":{
    "resourceVersion":"2436677", ...}, ...}}

允许书签有效地重新启动 watch 请求

正如前一节所示，通过使用标签或字段选择器，可以在资源的子集上执行 watch 会话。例如，这个请求将观察具有特定标签 mylabel 等于 foo 的 pod：

$ curl "$HOST/api/v1/namespaces/project1/pods?labelSelector=mylabel==foo&watch=true"

通过这个请求，你将只获得与你的选择器相匹配的pod的事件，而不是与你的请求不匹配的同一命名空间的其他pod的事件。

当重新启动观察请求时，你将能够使用与选择器相匹配的pod的资源版本；然而，在这个请求之后，其他pod上的许多事件可能已经发生。API服务器将不得不在你在这个旧的资源版本上重启观察时，执行对在此期间创建的所有pod的事件的过滤。

同样，由于API服务器在有限的时间内缓存这些事件，与最近的资源版本相比，旧的资源版本不再可用的风险更大。

为此，你可以使用 allowWatchBookmarks 参数，要求API服务器定期发送包含最新资源版本的 BOOKMARK 事件；这些可能是与你的选择分开的资源版本。

BOOKMARK 事件可能包含一个你请求的种类的对象（例如，如果你在观察pod，则是Pod种类），但这只包括 resourceVersion 字段。

{"type":"BOOKMARK",
  "object":{
    "kind":"Pod",
    "apiVersion":"v1",
    "metadata":{
      "resourceVersion":"2525115",
      "creationTimestamp":null
    },
    "spec":{
      "containers":null
    },
    "status":{}
  }
}

为了说明问题，这里有一个小实验。首先创建两（2）个pod，用选择器观察pod，只匹配第一个pod。你会得到一个匹配的pod的ADDED事件，而且，过了一段时间，你应该得到一个BOOKMARK事件（但不保证）。如果在此期间，该命名空间的pod上没有任何活动，resourceVersion 应该是相同的。

$ kubectl run nginx1 --image nginx --labels mylabel=foo
$ kubectl run nginx2 --image nginx --labels mylabel=bar
$ curl "$HOST/api/v1/namespaces/default/pods?
  labelSelector=mylabel==foo&
  watch=true&
  allowWatchBookmarks=true"
{"type":"ADDED","object":{
  "kind":"Pod","apiVersion":"v1","metadata":{
    "name":"nginx1","resourceVersion":"2520070", ...}, ...}}
{"type":"BOOKMARK","object":{
  "kind":"Pod","apiVersion":"v1","metadata":{
  "resourceVersion":"2520070", ...}, ...}}

在另一个终端，让我们用命令删除不匹配的pod，nginx2：

$ kubectl delete pods nginx2

你不应该收到这个变化的任何事件，因为 pod 不匹配请求选择器，但过了一会儿，你应该收到一个新的 BOOKMARK事件–这次是一个新的资源版本：

{"type":"BOOKMARK","object":{
  "kind":"Pod","apiVersion":"v1","metadata":{
  "resourceVersion":"2532566", ...}, ...}}

在这一点上，你可以从你的第一个终端停止观察请求。

接下来，你可以对命名空间的pod做一些修改–例如，删除 nginx1 pod，重新创建 nginx2 pod：

$ kubectl delete pods nginx1
$ kubectl run nginx2 --image nginx --labels mylabel=bar

现在，你可以使用资源版本 2532566 来重新启动观察请求，当请求停止时，你可以重新启动它：

curl "$HOST/api/v1/namespaces/default/pods?
  labelSelector=mylabel==foo&
  watch=true&
  allowWatchBookmarks=true&
  resourceVersion=2532566"

结果，你可以看到，当你删除这个pod的时候，你得到了 nginx1 的修改和删除的事件。你没有丢失任何事件，而且你使用了一个最新的资源版本，这对API服务器来说更有效率。

将结果分页

当你执行 list 请求时，结果有可能包含很多元素。在这种情况下，最好是通过发出几个请求来分页处理结果，每个响应将发送有限数量的元素。

对于这种情况，要使用 limit 和 continue 查询参数。第一个列表请求需要指定 limit 参数，以表明要返回的元素的最大数量。响应将在List结构的元数据中包含一个 continue 字段，该字段包含一个不透明的标记，以便在下一次请求中使用，以获得下一整块元素。

$ curl "$HOST/api/v1/pods?limit=1"
{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion": "2931316",
    "continue": <continue_token_1>,
    "remainingItemCount": 10
  },
  "items": [{ ... }]
}
$ curl "$HOST/api/v1/pods?limit=1&continue=<continue_token_1>"
{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion": "2931316",
    "continue": <continue_token_2>,
    "remainingItemCount": 9
  },
  "items": [{ ... }]
}

注意，你不需要对每个块使用相同的限制值。你可以把第一个请求的限制值定为1，第二个请求的限制值定为4，第三个请求的限制值定为6。

完整列表的一致性

请注意，两个响应中的 List 结构中的 resourceVersion 是相同的（即例子中的 “resourceVersion”: “2931316”）。当你运行第一个请求时，完整的响应被缓存在服务器上，你可以保证在接下来的几块中得到一个一致的结果，与你获得以下请求的时间以及在此期间对资源的修改无关。在这段时间内创建、修改或删除的资源不会影响下一个块的结果。

然而，有可能在你运行所有的请求之前，缓存就已经过期了。在这种情况下，你会收到一个代码为 410 的错误响应和一个新的继续值。因此，你有两个选择：

启动新的 List 请求，不使用 continue 参数，从头开始重新启动整个 List 会话。
用返回的 continue 值发起新的请求，但是以不一致的方式–也就是说，自第一个 chunk 被返回后，添加、修改或删除的资源将影响响应。

检测最后一个 chunk

你可以从响应的元数据中看到，remainItemCount 表示完成整个响应所需的剩余元素数量。然而，请注意，这个信息只适用于没有选择器的请求（无论是标签还是字段选择器）。

当运行没有选择器的分页列表请求时，服务器可以知道完整列表中的元素数量，并且能够在每次请求后指出剩余元素的数量。当发送完整列表的最后一个元素时，服务器也能够通过在列表结构的元数据中回复一个空的 continue 字段来表明这是最后一个块。

当使用选择器运行分页的列表请求时，服务器无法预先知道完整列表中的元素数量。由于这个原因，它不会在请求后发送剩余元素的数量，而且即使碰巧下一个块是空的，它也会发送一个continue 非空值。

你需要检查返回的列表是空的还是包含的元素少于 limit 字段中请求的元素，这样你就可以检测到最后一个chunk。

获取各种格式的结果

Kubernetes API可以以各种格式返回数据。你可以通过在HTTP请求中指定 Accept 头来询问你希望收到哪种格式。

以表格形式获取结果

kubectl客户端（和其他客户端）以表格的形式显示资源的列表。当运行 list 请求时，你可以要求API服务器给你必要的信息，通过使用 Accept 头来表示这种特定的格式来建立这种表格：

$ curl $HOST/api/v1/pods
-H 'Accept: application/json;as=Table;g=meta.k8s.io;v=v1'
{
  "kind": "Table",
  "apiVersion": "meta.k8s.io/v1",
  "metadata": {
    "resourceVersion": "2995797"
  },
  "columnDefinitions": [ { ... }, { ... }, { ... } ],
  "rows": [ { ... }, { ... } ]
}

这有助于客户端以表格格式显示任何资源的信息，包括自定义资源，因为自定义资源定义将包含关于在哪一列显示资源的哪个字段的信息。

对于请求的任何资源，响应的 kind 将总是 Table。第一个字段 columnDefinitions 描述了表格的每一列，第二个字段 rows 给出了结果中每个资源的列值。

列的定义

列的定义包括 name, type, format, description 和 priority 字段。name 是指该列的标题。type 是该列的 OpenAPI 类型定义（例如，整数、数字、字符串或布尔值）。

可选的 format 是列的类型的 OpenAPI 修改器，给出更多的格式化信息。整数类型的格式是 int32 和 int64，数字类型的格式是 float 和 double，而字符串类型的格式是 byte、binary、data、date-time、password 和 name。name 格式值不是 OpenAPI 规范的一部分，是 Kubernetes API 特有的。它向客户端指出包含资源名称的主列。

priority 字段是一个整数，表示一个列相对于其他列的重要性。当空间有限时，数值较高的列可能会被省略。

行数据

行包括 cells、conditions 和 object 字段。

cells 字段是一个与 columnDefinitions 数组长度相同的数组，包含当前行中显示的资源值。数组中每个元素的JSON类型和可选格式是由相应的列定义的类型和格式推断出来的。

conditions 字段给出了显示该行的具体属性。从Kubernetes 1.23开始，唯一定义的值是 “已完成”，表示该行显示的资源已经运行完成，可以给予较低的视觉优先级。

默认情况下，object 字段包含该列中显示的资源的元数据。你可以在列表请求中添加一个 includeObject 查询参数，以便不需要关于对象的信息（?includeObject=None），或者需要完整的对象（?includeObject=Object）。这个查询参数的默认值是Metadata，它只需要资源的元数据。例如，使用下面的方法来返回没有对象的信息作为行数据的一部分：

$ curl $HOST/api/v1/pods?includeObject=None
-H 'Accept: application/json;as=Table;g=meta.k8s.io;v=v1'

使用YAML格式

在前面的创建资源部分，你看到可以使用 YAML 格式来描述使用 Content-Type: application/yaml 头创建的资源。如果你没有指定这个头，你将需要用JSON格式来描述资源。

也可以使用 Accept: application/yaml 头来获得YAML格式的请求响应。这对Get和List请求有效，但也可以用于创建或更新资源的请求，返回它们的新值。例如，要获得YAML格式的所有pod的列表，请使用这个：

$ curl $HOST/api/v1/pods -H 'Accept: application/yaml'
kind: PodList
metadata:
  resourceVersion: "3009983"
items:
  [...]

或者，要创建一个新的Pod并获得YAML格式的创建的Pod，请使用以下内容：

$ curl $HOST/api/v1/namespaces/default/pods
    -H "Content-Type: application/yaml"
    -H 'Accept: application/yaml'
    --data-binary @pod.yaml

注意：不可能以 YAML 格式获得 Watch 请求的结果。

使用Protobuf格式

Protobuf 格式也可用于向 API 服务器发送数据或从其接收数据。为此，你需要在 Content-Type 或 Accept 中使用 application/vnd.kubernetes.protobuf 类型。

Kubernetes团队不鼓励在 Kubernetes 控制平面之外使用 Protobuf 格式，因为他们不能保证 Protobuf 消息会像JSON消息一样稳定。

如果你决定使用Protobuf格式，你需要知道API服务器不会交换纯粹的 Protobuf 数据，但它会给它添加一个头来检查 Kubernetes 版本之间的兼容性。

apimachinery 库包含Go代码，帮助开发者将数据序列化为各种格式，包括 Protobuf。第5章描述了如何使用这个库。

总结

本章讨论了如何运行 kubectl 以帮助理解其下执行的HTTP请求。然后，它展示了如何使用各种HTTP操作来创建、更新、应用、删除、获取、列出和观察资源的细节。最后，本章介绍了如何以几种格式获得这些操作的结果： JSON、YAML和Protobuf，或以表格的形式。

Client: Manager

Mon, 01 Feb 2021 00:00:00 +0000

controller-runtime 库提供的第一个重要抽象是 Manager / 管理器，它为在管理器内运行的所有控制器提供共享资源，包括：

读取和写入 Kubernetes 资源的 Kubernetes 客户端
用于从本地缓存中读取 Kubernetes 资源的缓存
用于注册所有 Kubernetes 本地和自定义资源的 scheme

要创建管理器，你需要使用提供的 New 函数，如下所示：

import (
      "flag"
      "sigs.k8s.io/controller-runtime/pkg/client/config"
      "sigs.k8s.io/controller-runtime/pkg/manager"
)
flag.Parse()                        ❶
mgr, err := manager.New(
     config.GetConfigOrDie(),
      manager.Options{},
)

❶解析命令行标志，如 GetConfigOrDie 来处理 --kubeconfig 标志；见下文。

第一个参数是 rest.Config 对象，见第 6 章 “连接到集群” 部分。请注意，在这个例子中，选择了 controller-runtime 库提供的 GetConfigOrDie() 实用函数，而不是使用 client-go 库的函数。

GetConfigOrDie() 函数将尝试获得一个配置来连接到集群：

通过获取 --kubeconfig 标志的值，如果定义了的话，并在这个路径上读取 kubeconfig 文件。为此，首先你需要执行 flag.Parse()
通过获取 KUBECONFIG 环境变量的值（如果定义了的话），并读取此路径下的 kubeconfig 文件
通过查看 in-cluster 配置（见第6章的 “集群内配置 “部分），如果定义了的话
通过读取 $HOME/.kube/config 文件

如果前面的情况都不可行，该函数将使程序退出，代码为1。第二个参数是一个用于选项的结构体。

一个重要的选项是 “Scheme"。默认情况下，如果你没有为这个选项指定任何值，将使用 Client-go 库提供的 Scheme。如果控制器只需要访问本地 Kubernetes 资源，这就足够了。然而，如果你想让控制器访问自定义资源，你将需要提供一个能够解决自定义资源的 Scheme。

例如，如果你想让控制器访问第九章中定义的自定义资源，你将需要在初始化时运行以下代码：

import (
      "k8s.io/apimachinery/pkg/runtime"
      clientgoscheme "k8s.io/client-go/kubernetes/scheme"
      mygroupv1alpha1 "github.com/myid/myresource-crd/pkg/apis/mygroup.example.com/v1alpha1"
)
scheme := runtime.NewScheme()                  ❶
clientgoscheme.AddToScheme(scheme)             ❷
mygroupv1alpha1.AddToScheme(scheme)            ❸
mgr, err := manager.New(
      config.GetConfigOrDie(),
      manager.Options{
            Scheme: scheme,                    ❹
      },
)

❶ 创建一个新的空 scheme

❷ 使用 Client-go 库添加本地 Kubernetes 资源

❷ 将 mygroup/v1alpha1 的资源添加到 scheme 中，其中包含我们的自定义资源

❹ 在这个管理器中使用这个 scheme

Client: openapi规范

Mon, 01 Feb 2021 00:00:00 +0000

Kubernetes 的API 是HTTP REST API。Kubernetes 团队提供了 OpenAPI 格式的API规范，V2格式的规范在 https://github.com/kubernetes/kubernetes/tree/master/api/openapi-spec，Kubernetes v1.24 v3 格式的规范在 https://github.com/kubernetes/kubernetes/tree/master/api/openapi-spec/v3。

这些规范也可以从 API 服务器的这些路径访问： /openapi/v2 和 /openapi/v3 。

OpenAPI规范是由不同部分组成的，其中有路径列表和定义列表。路径是你用来请求这个API的URL，对于每个路径，规范给出了不同的操作，如 get、delte 或 post 。然后，对于每个操作，规范指出了什么是请求的参数和主体格式，以及什么是可能的响应代码和相关的响应主体格式。

请求和响应的参数和主体可以是简单的类型，也可以是更普遍的包含数据的结构。定义列表包括帮助建立操作的请求和响应的参数和主体的数据结构。

图1-2是一个 User API 规范的简化视图。这个API可以接受两个不同的路径： /user/{userId} 和 /user。第一个路径，/user/{userId}，可以接受两个操作，分别是 get 和 delete，用来接收特定用户的信息，给出其用户ID；以及删除特定用户的信息，给出其用户ID。第二个路径，/user，可以接受一个单一的操作，post，以添加一个新的用户，给定其信息。

在这个API中，给出了一个 User 结构体的定义，描述了一个用户的信息：其ID、first name 和 last name。这个数据结构被用于第一条路径上的 get 操作的响应体中，以及第二条路径上的 post 操作的请求体中。

Client: controller-runtime package概况

Mon, 01 Feb 2021 00:00:00 +0000

https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg

pkg 包提供了用于构建 controller 控制器的库。控制器实现了 Kubernetes API，是构建 operator、workload API、配置API、自动缩放器等的基础。

client

客户端为读写Kubernetes对象提供了一个读+写的客户端。

cache

缓存提供了一个读客户端，用于从本地缓存中读取对象。缓存可以注册 handler 来响应更新缓存的事件。

manager

Manager是创建 controller 控制器的必要条件，并提供 controller 的共享依赖关系，如客户端、缓存、scheme 等。 controller 应该通过 manager 调用 Manager.Start 来启动。

Controller

Controller 通过响应事件（对象创建、更新、删除）来实现 Kubernetes API，并确保对象的 Spec 中指定的状态与系统的状态相匹配。这被称为 reconcile（调和）。如果它们不匹配，Controller 将根据需要创建/更新/删除对象，使它们匹配。

Controller 被实现为处理 reconcile.Requests（为特定对象 reconcile 状态的请求）的工作队列。

与 http handler 不同的是，Controller 不直接处理事件，而是将 Requests 入列来最终 reconcile 对象。这意味着多个事件的处理可能会被批量进行，而且每次 reconcile 都必须读取系统的全部状态。

Controller 需要提供一个 Reconciler 来执行从工作队列中拉出的工作。
Controller 需要配置 Watches，以便将 reconcile.Requests 入列并对事件进行响应。

Webhook

Admission Webhooks 是一种扩展 kubernetes APIs 的机制。Webhooks 可以配置目标事件类型（对象创建、更新、删除），API 服务器将在某些事件发生时向它们发送 AdmissionRequests。Webhooks 可以修改和（或）验证嵌入在 AdmissionReview 请求中的对象，并将响应发回给 API 服务器。

有2种类型的 Admission Webhooks ：修改（mutating）和验证（validating）的 Admission Webhooks 。修改的 webhook 是用来在 API 服务器接纳之前修改 core API 对象或 CRD 实例。验证 webhook 用于验证对象是否符合某些要求。

Admission Webhooks 需要提供 Handler（s）来处理收到的 AdmissionReview 请求。

Reconciler

Reconciler 是提供给 Controller 的一个函数，可以在任何时候用对象的名称和命名空间来调用。当被调用时，Reconciler 将确保系统的状态与 Reconciler 被调用时在对象中指定的内容相匹配。

例子：为一个 ReplicaSet 对象调用 Reconciler。ReplicaSet 指定了5个副本，但系统中只存在 3 个 Pod。Reconciler 又创建了2个Pod，并将其 OwnerReference 设置为指向 ReplicaSet，并设置 controller=true。

Reconciler 包含 Controller 的所有业务逻辑。
Reconciler 通常只对单一对象类型工作。- 例如，它将只对 ReplicaSets 进行调节。对于单独的类型，使用单独的 Controller。如果你想从其他对象触发 reconcile，你可以提供一个映射（例如所有者引用/owner references），将触发 reconcile 的对象映射到被 reconcile 的对象。
Reconciler 被提供给要 reconcile 的对象的名称/命名空间。
Reconciler 不关心负责触发 Reconcile 的事件内容或事件类型。例如，ReplicaSet 是否被创建或更新并不重要，Reconciler 总是将系统中的 Pod 数量与它被调用时在对象中指定的数量进行比较。

Source

resource.Source 是 Controller.Watch 的参数，提供了事件流。事件通常来自于 watch Kubernetes APIs（例如：Pod Create, Update, Delete）。

例如：source.Kind 使用 Kubernetes API Watch 端点，为 GroupVersionKind 提供创建、更新、删除事件。

Source 通常通过 Watch API 为 Kubernetes 对象提供事件流（如对象创建、更新、删除）。
在几乎所有情况下，用户都应该只使用所提供的 Source 实现，而不是实现自己的。

EventHandler

handler.EventHandler 是 Controller.Watch 的参数，它在响应事件时入队 reconcile.Requests。

例如：一个来自 Source 的 Pod 创建事件被提供给 eventhandler.EnqueueHandler，它入队包含 Pod 的名称/命名空间的reconcile.Request。

EventHandlers 通过入队 reconcile.Requests 来为一个或多个对象处理事件。
EventHandlers 可以将一个对象的事件映射到同一类型的另一个对象的 reconcile.Request 上。
EventHandlers 可以将一个对象的事件映射到不同类型的另一个对象的 reconcile.Request 。例如，将 Pod 事件映射到拥有它的 ReplicaSet 的 reconcile.Request 上。
EventHandlers 可以将一个对象的事件映射到相同或不同类型的对象的多个 reconcile.Request 。例如，将一个 Node 事件映射到响应集群大小事件的对象上。
在几乎所有情况下，用户都应该只使用所提供的 EventHandler 实现，而不是实现自己的。

Predicate

predicate.Predicate 是 Controller.Watch 的一个可选的参数，用于过滤事件。这使得常见的过滤器可以被重复使用和组合。

Predicate 接收一个事件，并返回bool（ true为enqueue ）。
Predicate 是可选的参数
用户应该使用所提供的 Predicate 实现，但可以实现额外的 Predicate，例如：generation 改变，标签选择器改变等。

PodController 图例

Source 提供事件：

&source.KindSource{&v1.Pod{}} -> (Pod foo/bar Create Event)

EventHandlers 入队请求：

&handler.EnqueueRequestForObject{} -> (reconcile.Request{types.NamespaceName{Name: "foo", Namespace: "bar"}})

Reconciler 被调用，携带参数Request：

Reconciler(reconcile.Request{types.NamespaceName{Name: "foo", Namespace: "bar"}})

用法

下面的例子显示了创建一个新的 Controller 程序，该程序响应 Pod 或 ReplicaSet 事件，对 ReplicaSet 对象进行 Reconcile。Reconciler 函数只是给 ReplicaSet 添加一个标签。

参见 examples/builtins/main.go 中的使用实例。

Controller 实例：

1. Watch ReplicaSet 和 Pods Source
- 1.1 ReplicaSet -> handler.EnqueueRequestForObject – 用 ReplicaSet 的命名空间和名称来入队请求。
- 1.2 Pod (由 ReplicaSet 创建) -> handler.EnqueueRequestForOwnerHandler –以拥有的 ReplicaSet 命名空间和名称来入队Request。
1. 响应事件，对 ReplicaSet 进行 Reconcile
- 2.1 创建 ReplicaSet 对象 -> 读取 ReplicaSet，尝试读取 Pods -> 如果空缺就创建 Pods。
- 2.2 创建 Pods 锁触发的 Reconciler -> 读取 ReplicaSet 和 Pods，什么都不做。
- 2.3 从其他角色中刪除Pods而触发Reconciler -> 读取 ReplicaSet 和 Pods，创建替代Pods。

监视和事件处理

Controller 可以观察多种类型的对象（如Pods、ReplicaSets和 deployment），但他们只 reconcile 一个类型。当一种类型的对象必须更新以响应另一种类型的对象的变化时，EnqueueRequestsFromMapFunc 可用于将事件从一种类型映射到另一种类型。例如，通过重新 reconcile 某些API的所有实例来响应集群大小调整事件（添加/删除节点）。

Deployment Controller 可能使用 EnqueueRequestForObject 和 EnqueueRequestForOwner 来：

观察 Deployment 事件–入队 Deployment 的命名空间和名称。
观察 ReplicaSet 事件– 入队创建 ReplicaSet 的 Deployment 的命名空间和名称（例如，所有者/Owner）。

注意：reconcile.Requests 在入队的时候会被去重。同一个 ReplicaSet 的许多 Pod 事件可能只触发1个 reconcile 调用，因为每个事件都会导致 handler 试图为 ReplicaSet 入队相同的 reconcile.Request。

Controller的编写技巧

Reconciler 运行时的复杂性：

最好是编写 Controllers 来执行N次O(1) reconcile（例如对N个不同的对象），而不是执行1次O(N) reconcile（例如对一个管理着N个其他对象的单一对象）。
例子：如果你需要更新所有服务以响应一个节点的添加– reconcile 服务但观察节点（转变为服务对象的名称/命名空间），而不是 reconcile 节点并更新服务。

事件复用：

对同一名称/命名空间的 reconcile 请求在入队时被批量和去重处理。这使 Controller 能够优雅地处理单个对象的大量事件。将多个事件源复用到一个对象类型上，将对不同对象类型的事件进行批量请求。
例如： ReplicaSet 的 Pod 事件被转换为 ReplicaSet 名称/命名空间，因此 ReplicaSet 将只对来自多个 Pod 的多个事件进行1次Reconciled。


builder	Package builder 封装了其他 controller-runtime 库，并公开了构建普通 controller 的简单模式。
cache	Package cache provides object caches that act as caching client.Reader instances and help drive Kubernetes-object-based event handlers. 包缓存提供对象缓存，作为缓存客户端.阅读器实例，帮助驱动基于Kubernetes对象的事件处理程序。
certwatcher	Package certwatcher is a helper for reloading Certificates from disk to be used with tls servers.
client	Package client contains functionality for interacting with Kubernetes API servers.
cluster
config	Package config contains functionality for interacting with configuration for controller-runtime components.
controller	Package controller provides types and functions for building Controllers.
conversion	Package conversion provides interface definitions that an API Type needs to implement for it to be supported by the generic conversion webhook handler defined under pkg/webhook/conversion.
envtest	Package envtest provides libraries for integration testing by starting a local control plane
event	Package event contains the definitions for the Event types produced by source.Sources and transformed into reconcile.Requests by handler.EventHandler.
finalizer
handler	Package handler defines EventHandlers that enqueue reconcile.Requests in response to Create, Update, Deletion Events observed from Watching Kubernetes APIs.
healthz	Package healthz contains helpers from supporting liveness and readiness endpoints.
leaderelection	Package leaderelection contains a constructor for a leader election resource lock.
log	Package log contains utilities for fetching a new logger when one is not already available.
manager	Package manager is required to create Controllers and provides shared dependencies such as clients, caches, schemes, etc.
metrics	Package metrics contains controller related metrics utilities
predicate	Package predicate defines Predicates used by Controllers to filter Events before they are provided to EventHandlers.
ratelimiter	Package ratelimiter defines rate limiters used by Controllers to limit how frequently requests may be queued.
reconcile	Package reconcile defines the Reconciler interface to implement Kubernetes APIs.
recorder	Package recorder defines interfaces for working with Kubernetes event recorders.
scheme	Package scheme contains utilities for gradually building Schemes, which contain information associating Go types with Kubernetes groups, versions, and kinds.
source	Package source provides event streams to hook up to Controllers with Controller.Watch.
webhook	Package webhook provides methods to build and bootstrap a webhook server.

Concepts: Kubernetes 对象管理

Mon, 01 Feb 2021 00:00:00 +0000

https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/object-management/

管理技巧

警告： 应该只使用一种技术来管理 Kubernetes 对象。混合和匹配技术作用在同一对象上将导致未定义行为。

管理技术	作用于	建议的环境	支持的写者	学习难度
指令式命令	活跃对象	开发项目	1+	最低
指令式对象配置	单个文件	生产项目	1	中等
声明式对象配置	文件目录	生产项目	1+	最高

指令式命令

使用指令式命令时，用户可以在集群中的活动对象上进行操作。用户将操作传给 kubectl 命令作为参数或标志。

指令式对象配置

在指令式对象配置中，kubectl 命令指定操作（创建，替换等），可选标志和至少一个文件名。指定的文件必须包含 YAML 或 JSON 格式的对象的完整定义。

声明式对象配置

使用声明式对象配置时，用户对本地存储的对象配置文件进行操作，但是用户未定义要对该文件执行的操作。 kubectl 会自动检测每个文件的创建、更新和删除操作。这使得配置可以在目录上工作，根据目录中配置文件对不同的对象执行不同的操作。

Docs: 初始化集群

Mon, 24 Nov 2025 00:00:00 +0000

参考官方文档：

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/

需要注意的问题

coredns 的版本问题

[sudo] password for sky: 
[init] Using Kubernetes version: v1.34.2
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action beforehand using 'kubeadm config images pull'
W1127 11:14:12.643662   17241 checks.go:827] detected that the sandbox image "registry.k8s.io/pause:3.10" of the container runtime is inconsistent with that used by kubeadm. It is recommended to use "192.168.3.193:5000/k8s-proxy/pause:3.10.1" as the CRI sandbox image.
[preflight] Some fatal errors occurred:
	[ERROR ImagePull]: failed to pull image 192.168.3.193:5000/k8s-proxy/coredns:v1.12.1: failed to pull image 192.168.3.193:5000/k8s-proxy/coredns:v1.12.1: Error response from daemon: failed to resolve reference "192.168.3.193:5000/k8s-proxy/coredns:v1.12.1": 192.168.3.193:5000/k8s-proxy/coredns:v1.12.1: not found
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
error: error execution phase preflight: preflight checks failed
To see the stack trace of this error execute with --v=5 or higher

这里 coredns 报错, 我们用 kubeadm config images pull 可以看到需要用到的镜像:

$ kubeadm config images pull

[config/images] Pulled registry.k8s.io/kube-apiserver:v1.35.4
[config/images] Pulled registry.k8s.io/kube-controller-manager:v1.35.4
[config/images] Pulled registry.k8s.io/kube-scheduler:v1.35.4
[config/images] Pulled registry.k8s.io/kube-proxy:v1.35.4
[config/images] Pulled registry.k8s.io/coredns/coredns:v1.13.1
[config/images] Pulled registry.k8s.io/pause:3.10.1
[config/images] Pulled registry.k8s.io/etcd:3.6.6-0

Kubernetes 大多数核心组件镜像（kube-apiserver、kube-scheduler、etcd、pause 等）都是单层路径，而 CoreDNS 特别用了两层路径 coredns/coredns。这会导致在使用代理仓库时出错:

$ kubeadm config images pull --image-repository=192.168.3.193:5000/k8s-proxy

[config/images] Pulled 192.168.3.193:5000/k8s-proxy/kube-apiserver:v1.34.2
[config/images] Pulled 192.168.3.193:5000/k8s-proxy/kube-controller-manager:v1.34.2
[config/images] Pulled 192.168.3.193:5000/k8s-proxy/kube-scheduler:v1.34.2
[config/images] Pulled 192.168.3.193:5000/k8s-proxy/kube-proxy:v1.34.2
error: failed to pull image "192.168.3.193:5000/k8s-proxy/coredns:v1.12.1": failed to pull image 192.168.3.193:5000/k8s-proxy/coredns:v1.12.1: Error response from daemon: failed to resolve reference "192.168.3.193:5000/k8s-proxy/coredns:v1.12.1": 192.168.3.193:5000/k8s-proxy/coredns:v1.12.1: not found
To see the stack trace of this error execute with --v=5 or higher

要修订这个问题,就需要告知 kubeadm coredns 的代理仓库

初始化集群

准备 kubeadm.yaml

pod-network-cidr 尽量用 10.244.0.0/16 这个范围，不然有些网络插件会需要额外的配置。

cri-socket 的配置参考：

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime

因为前面用的 Docker Engine 和 cri-dockerd ，因此这里的 cri-socket 需要指定为 “unix:///var/run/cri-dockerd.sock”。

apiserver-advertise-address 需要指定为当前节点的 IP 地址，因为当前节点是单节点，因此这里指定为当前机器的 IP 地址如 192.168.3.100。

新建一个 kubeadm.yaml 文件：

mkdir -p ~/work/soft/k8s/
cd ~/work/soft/k8s/
vi kubeadm.yaml

内容为:

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
nodeRegistration:
  criSocket: unix:///var/run/cri-dockerd.sock

---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.35.4
imageRepository: 192.168.3.193:5000/k8s-proxy
networking:
  podSubnet: 10.244.0.0/16
dns:
  imageRepository: 192.168.3.193:5000/k8s-proxy/coredns
  imageTag: v1.13.1
etcd:
  local:
    imageRepository: 192.168.3.193:5000/k8s-proxy
    imageTag: 3.6.6-0

执行 init

执行:

sudo kubeadm init --config=kubeadm.yaml

输出为：

[init] Using Kubernetes version: v1.35.4
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action beforehand using 'kubeadm config images pull'
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [debian13 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.3.232]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [debian13 localhost] and IPs [192.168.3.232 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [debian13 localhost] and IPs [192.168.3.232 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "super-admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/instance-config.yaml"
[patches] Applied patch of type "application/strategic-merge-patch+json" to target "kubeletconfiguration"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests"
[kubelet-check] Waiting for a healthy kubelet at http://127.0.0.1:10248/healthz. This can take up to 4m0s
[kubelet-check] The kubelet is healthy after 500.416007ms
[control-plane-check] Waiting for healthy control plane components. This can take up to 4m0s
[control-plane-check] Checking kube-apiserver at https://192.168.3.232:6443/livez
[control-plane-check] Checking kube-controller-manager at https://127.0.0.1:10257/healthz
[control-plane-check] Checking kube-scheduler at https://127.0.0.1:10259/livez
[control-plane-check] kube-controller-manager is healthy after 1.001317452s
[control-plane-check] kube-scheduler is healthy after 1.502089525s
[control-plane-check] kube-apiserver is healthy after 3.000477876s
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node debian13 as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
[mark-control-plane] Marking the node debian13 as control-plane by adding the taints [node-role.kubernetes.io/control-plane:NoSchedule]
[bootstrap-token] Using token: ki33kg.5vpalsrlaa9bjvn2
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.3.232:6443 --token ki33kg.5vpalsrlaa9bjvn2 \
	--discovery-token-ca-cert-hash sha256:dba4e956a1e678da2319e29ce1b880bc4b21771cd5635dfa3117b7c2f409af29

根据提示操作：

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

对于测试用的单节点，去除 master/control-plane 的污点：

kubectl taint nodes --all node-role.kubernetes.io/control-plane-

执行：

kubectl get node

能看到此时节点的状态会是 NotReady：

NAME       STATUS     ROLES           AGE   VERSION
debian13   NotReady   control-plane   53s   v1.35.4

执行：

kubectl describe node debian13

能看到节点的错误信息：

Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  MemoryPressure   False   Wed, 22 Apr 2026 15:24:55 +0800   Wed, 22 Apr 2026 15:24:53 +0800   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Wed, 22 Apr 2026 15:24:55 +0800   Wed, 22 Apr 2026 15:24:53 +0800   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Wed, 22 Apr 2026 15:24:55 +0800   Wed, 22 Apr 2026 15:24:53 +0800   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            False   Wed, 22 Apr 2026 15:24:55 +0800   Wed, 22 Apr 2026 15:24:53 +0800   KubeletNotReady              container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

需要继续安装网络插件。

安装网络插件

安装 flannel

参考官方文档： https://github.com/flannel-io/flannel#deploying-flannel-with-kubectl

kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

如果一切正常，就能看到 k8s 集群内的 pod 都启动完成状态为 Running：

$ k get pods -A

NAMESPACE      NAME                               READY   STATUS    RESTARTS       AGE
kube-flannel   kube-flannel-ds-mdzgj              1/1     Running   0              39s
kube-system    coredns-7f58b9688b-9rdzj           1/1     Running   0              2m44s
kube-system    coredns-7f58b9688b-lv4jr           1/1     Running   0              2m44s
kube-system    etcd-debian13                      1/1     Running   0              2m51s
kube-system    kube-apiserver-debian13            1/1     Running   1 (5m8s ago)   2m52s
kube-system    kube-controller-manager-debian13   1/1     Running   0              2m51s
kube-system    kube-proxy-qzhkw                   1/1     Running   0              2m44s
kube-system    kube-scheduler-debian13            1/1     Running   0              2m51s

如果发现 kube-flannel-ds pod 的状态总是 CrashLoopBackOff：

 k get pods -A
NAMESPACE      NAME                               READY   STATUS              RESTARTS        AGE
kube-flannel   kube-flannel-ds-ts6n8              0/1     CrashLoopBackOff    2 (22s ago)     42s

继续查看 pod 的具体错误信息：

k describe pods -n kube-flannel kube-flannel-ds-ts6n8

发现报错 “Back-off restarting failed container kube-flannel in pod kube-flannel”：

Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Normal   Scheduled  117s                default-scheduler  Successfully assigned kube-flannel/kube-flannel-ds-ts6n8 to debian12
  Normal   Pulled     116s                kubelet            Container image "ghcr.io/flannel-io/flannel-cni-plugin:v1.6.2-flannel1" already present on machine
  Normal   Created    116s                kubelet            Created container: install-cni-plugin
  Normal   Started    116s                kubelet            Started container install-cni-plugin
  Normal   Pulled     115s                kubelet            Container image "ghcr.io/flannel-io/flannel:v0.26.4" already present on machine
  Normal   Created    115s                kubelet            Created container: install-cni
  Normal   Started    115s                kubelet            Started container install-cni
  Normal   Pulled     28s (x5 over 114s)  kubelet            Container image "ghcr.io/flannel-io/flannel:v0.26.4" already present on machine
  Normal   Created    28s (x5 over 114s)  kubelet            Created container: kube-flannel
  Normal   Started    28s (x5 over 114s)  kubelet            Started container kube-flannel
  Warning  BackOff    2s (x10 over 110s)  kubelet            Back-off restarting failed container kube-flannel in pod kube-flannel-ds-ts6n8_kube-flannel(1e03c200-2062-4838

此时应该去检查准备工作中 “开启模块” 一节的内容是不是有疏漏。

补救之后，就能看到 kube-flannel-ds 这个 pod 正常运行了：

k get pods -A
NAMESPACE      NAME                               READY   STATUS    RESTARTS        AGE
kube-flannel   kube-flannel-ds-ts6n8              1/1     Running   7 (9m27s ago)   15m

Source: API

Wed, 14 May 2025 00:00:00 +0000

k8s 的 API：

pod
replicationset
service
deployment
job
cronjob
statefulset
daemonset
cronjob

Source: register.go

Wed, 14 May 2025 00:00:00 +0000

就注册了一个类型 AdmissionReview：

// Adds the list of known types to the given scheme.
func addKnownTypes(scheme *runtime.Scheme) error {
	scheme.AddKnownTypes(SchemeGroupVersion,
		&AdmissionReview{},
	)
	metav1.AddToGroupVersion(scheme, SchemeGroupVersion)
	return nil
}

Kubernetes学习笔记 – Kubernetes学习笔记

Source: 概述

api 信息

api 列表

API 版本

api 代码结构

doc.go

generated.pb.go

generated.proto

register.go

types.go

types_swagger_doc_generated.go

zz_generated.deepcopy.go

zz_generated.prerelease-lifecycle.go

Concepts: pod

什么是 Pod？

使用 Pod

Pod 怎样管理多个容器

资源共享和通信

Pod 中的存储

Pod 联网

Concepts: 概述

为什么需要 Kubernetes，它能做什么？

Kubernetes 不是什么

Docs: Sidecar Container概述

资料

官方正式资料

社区介绍资料

相关项目的处理

Istio

信息1

信息2

Knative

dapr

Docs: KEP753: Sidecar Container

相关issue

Docs: 推翻KEP753的讨论

起于derekwaynecarr的发言

其他人的意见

Docs: 准备工作

系统更新

swap 分区

开启模块

container runtime

安装 docker

安装 containerd

安装 helm

Source: 概述

介绍

核心类型

HTTP 方法

使用场景

Source: 概述

介绍

核心类型

核心 API 方法

关键字段解析

(1) WebhookClientConfig

工作原理

Source: 概述

介绍

核心 API 资源类型

核心 API 方法

工作原理

实际应用场景

源码学习路径

Source: 概述

介绍

核心 API 资源类型

关键工作流程

实际应用场景

源码学习路径

调试技巧

设计意义

Source: 概述

介绍

核心 API 资源类型

源码学习路径

设计意义

Source: 概述

(1) `WebhookClientConfig`

`Waiting` （等待）

`Running`（运行中）

`Terminated`（已终止）