这是本节的多页打印视图。
点击此处打印 .
返回本页常规视图 .
参考
这是 Kubernetes 文档的参考部分。
API 参考
官方支持的客户端库
如果您需要通过编程语言调用 Kubernetes API,您可以使用
客户端库 。以下是官方支持的客户端库:
CLI
kubectl - 主要的 CLI 工具,用于运行命令和管理 Kubernetes 集群。
kubeadm - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。
组件
配置 API
本节包含用于配置 kubernetes 组件或工具的 "未发布" API 的文档。
尽管这些 API 对于用户或操作者使用或管理集群来说是必不可少的,
它们大都没有以 RESTful 的方式在 API 服务器上公开。
kubeadm 的配置 API
设计文档
Kubernetes 功能的设计文档归档,不妨考虑从
Kubernetes 架构 和
Kubernetes 设计概述
开始阅读。
1 - 词汇表
2 - API 概述
本文提供了 Kubernetes API 的参考信息。
REST API 是 Kubernetes 的基本结构。
所有操作和组件之间的通信及外部用户命令都是调用 API 服务器处理的 REST API。
因此,Kubernetes 平台视一切皆为 API 对象,
且它们在 API 中有相应的定义。
Kubernetes API 参考 列
出了 Kubernetes v1.23 版本的 API。
如需了解一般背景信息,请查阅 Kubernetes API 。
Kubernetes API 控制访问 描述了客户端如何
向 Kubernetes API 服务器进行身份认证以及他们的请求如何被鉴权。
API 版本控制
JSON 和 Protobuf 序列化模式遵循相同的模式更改原则。
以下描述涵盖了这两种格式。
API 版本控制和软件版本控制是间接相关的。
API 和发布版本控制提案
描述了 API 版本控制和软件版本控制间的关系。
不同的 API 版本代表着不同的稳定性和支持级别。
你可以在 API 变更文档
中查看到更多的不同级别的判定标准。
下面是每个级别的摘要:
Alpha:
版本名称包含 alpha
(例如,v1alpha1
)。
软件可能会有 Bug。启用某个特性可能会暴露出 Bug。
某些特性可能默认禁用。
对某个特性的支持可能会随时被删除,恕不另行通知。
API 可能在以后的软件版本中以不兼容的方式更改,恕不另行通知。
由于缺陷风险增加和缺乏长期支持,建议该软件仅用于短期测试集群。
Stable:
版本名称如 vX
,其中 X
为整数。
特性的稳定版本会出现在后续很多版本的发布软件中。
API 组
API 组
能够简化对 Kubernetes API 的扩展。
API 组信息出现在REST 路径中,也出现在序列化对象的 apiVersion
字段中。
以下是 Kubernetes 中的几个组:
核心 (也叫 legacy )组的 REST 路径为 /api/v1
。
核心组并不作为 apiVersion
字段的一部分,例如, apiVersion: v1
。
指定的组位于 REST 路径 /apis/$GROUP_NAME/$VERSION
,
并且使用 apiVersion: $GROUP_NAME/$VERSION
(例如, apiVersion: batch/v1
)。
你可以在 Kubernetes API 参考文档
中查看全部的 API 组。
启用或禁用 API 组
资源和 API 组是在默认情况下被启用的。
你可以通过在 API 服务器上设置 --runtime-config
参数来启用或禁用它们。
--runtime-config
参数接受逗号分隔的 <key>[=<value>]
对,
来描述 API 服务器的运行时配置。如果省略了 =<value>
部分,那么视其指定为 =true
。
例如:
禁用 batch/v1
, 对应参数设置 --runtime-config=batch/v1=false
启用 batch/v2alpha1
, 对应参数设置 --runtime-config=batch/v2alpha1
说明: 启用或禁用组或资源时,
你需要重启 API 服务器和控制器管理器来使 --runtime-config
生效。
持久化
Kubernetes 通过 API 资源来将序列化的状态写到 etcd 中存储。
接下来
2.1 - Kubernetes API 概念
本页描述 Kubernetes API 的通用概念。
Kubernetes API 是基于资源的(RESTful)、通过 HTTP 提供的编程接口。
API 支持通过标准的 HTTP 动词(POST、PUT、PATCH、DELETE 和 GET)
检视、创建、更新和删除主要资源,为很多允许细粒度权限控制的对象提供子资源
(如将 Pod 绑定到节点上),并且出于便利性或效率考虑,支持并提供这些资源的
不同表示形式。
Kubernetes API 还通过 "watch" 和一致性的列表支持高效的资源变更通知,
从而允许其他组件对资源的状态进行高效的缓存和同步。
标准 API 术语
大多数 Kubernetes API 资源类型都是
对象 :
它们代表的是集群中某一概念的具体实例,例如一个 Pod 或名字空间。
为数不多的几个 API 资源类型是“虚拟的” - 它们通常代表的是操作而非对象本身,
例如访问权限检查(使用 POST 请求发送一个 JSON 编码的 SubjectAccessReview
负载到 subjectaccessreviews
资源)。
所有对象都有一个唯一的名字,以便支持幂等的创建和检视操作,不过如果虚拟资源类型
不可检视或者不要求幂等,可以不具有唯一的名字。
Kubernetes 一般会利用标准的 RESTful 术语来描述 API 概念:
资源类型(Resource Type) 是在 URL 中使用的名称(pods
、namespaces
、services
)
所有资源类型都有具有一个 JSON 形式(其对象的模式定义)的具体表示,称作类别(Kind)
某资源类型的实例的列表称作 集合(Collection)
资源类型的单个实例被称作 资源(Resource)
所有资源类型要么是集群作用域的(/apis/GROUP/VERSION/*
),要么是名字空间
作用域的(/apis/GROUP/VERSION/namespaces/NAMESPACE/*
)。
名字空间作用域的资源类型会在其名字空间被删除时也被删除,并且对该资源类型的
访问是由定义在名字空间域中的授权检查来控制的。
下列路径用来检视集合和资源:
集群作用域的资源:
GET /apis/GROUP/VERSION/RESOURCETYPE
- 返回指定资源类型的资源的集合
GET /apis/GROUP/VERSION/RESOURCETYPE/NAME
- 返回指定资源类型下名称为 NAME 的资源
名字空间作用域的资源:
GET /apis/GROUP/VERSION/RESOURCETYPE
- 返回所有名字空间中指定资源类型的全部实例的集合
GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE
- 返回名字空间 NAMESPACE 内给定资源类型的全部实例的集合
GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME
- 返回名字空间 NAMESPACE 中给定资源类型的名称为 NAME 的实例
由于名字空间本身是一个集群作用域的资源类型,你可以通过 GET /api/v1/namespaces/
检视所有名字空间的列表,使用 GET /api/v1/namespaces/NAME
查看特定名字空间的
详细信息。
几乎所有对象资源类型都支持标准的 HTTP 动词 - GET、POST、PUT、PATCH 和 DELETE。
Kubernetes 使用术语 list 来描述返回资源集合的操作,以便与返回单个资源的、
通常称作 get 的操作相区分。
某些资源类型有一个或多个子资源(Sub-resource),表现为对应资源下面的子路径:
集群作用域的子资源:GET /apis/GROUP/VERSION/RESOURCETYPE/NAME/SUBRESOURCE
名字空间作用域的子资源:GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME/SUBRESOURCE
取决于对象是什么,每个子资源所支持的动词有所不同 - 参见 API 文档以了解更多信息。
跨多个资源来访问其子资源是不可能的 - 如果需要这一能力,则通常意味着需要一种
新的虚拟资源类型了。
高效检测变更
为了使客户端能够构造一个模型来表达集群的当前状态,所有 Kubernetes 对象资源类型
都需要支持一致的列表和一个称作 watch 的增量变更通知信源(feed)。
每个 Kubernetes 对象都有一个 resourceVersion
字段,代表该资源在下层数据库中
存储的版本。检视资源集合(名字空间作用域或集群作用域)时,服务器返回的响应
中会包含 resourceVersion
值,可用来向服务器发起 watch 请求。
服务器会返回所提供的 resourceVersion
之后发生的所有变更(创建、删除和更新)。
这使得客户端能够取回当前的状态并监视其变更,且不会错过任何变更事件。
客户端的监视连接被断开时,可以从最后返回的 resourceVersion
重启新的监视连接,
或者执行一个新的集合请求之后从头开始监视操作。
参阅资源版本语义 以了解更多细节。
例如:
列举给定名字空间中的所有 Pods:
GET /api/v1/namespaces/test/pods
---
200 OK
Content-Type: application/json
{
"kind": "PodList",
"apiVersion": "v1",
"metadata": {"resourceVersion":"10245"},
"items": [...]
}
从资源版本 10245 开始,以 JSON 对象的形式接收所有创建、删除或更新操作的通知:
GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245
---
200 OK
Transfer-Encoding: chunked
Content-Type: application/json
{
"type": "ADDED",
"object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10596", ...}, ...}
}
{
"type": "MODIFIED",
"object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "11020", ...}, ...}
}
...
给定的 Kubernetes 服务器只会保留一定的时间内发生的历史变更列表。
使用 etcd3 的集群默认保存过去 5 分钟内发生的变更。
当所请求的 watch 操作因为资源的历史版本不存在而失败,客户端必须能够处理
因此而返回的状态代码 410 Gone
,清空其本地的缓存,重新执行 list 操作,
并基于新的 list 操作所返回的 resourceVersion
来开始新的 watch 操作。
大多数客户端库都能够提供某种形式的、包含此逻辑的工具。
(在 Go 语言客户端库中,这一设施称作 Reflector
,位于
k8s.io/client-go/cache
包中。)
监视书签
为了处理历史窗口过短的问题,我们引入了 bookmark(书签)
监视事件的概念。
该事件是一种特殊事件,用来标示客户端所请求的、指定的 resourceVersion
之前
的所有变更都以被发送。该事件中返回的对象是所请求的资源类型,但其中仅包含
resourceVersion
字段,例如:
GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245&allowWatchBookmarks=true
---
200 OK
Transfer-Encoding: chunked
Content-Type: application/json
{
"type": "ADDED",
"object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10596", ...}, ...}
}
...
{
"type": "BOOKMARK",
"object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "12746"} }
}
通过在 watch 请求中设置 allowWatchBookmarks=true
选项,可以请求 bookmark
事件,但是客户端不能假定服务器端会按某特定时间间隔返回书签事件,甚至也不能
假定服务器一定会发送 bookmark
事件。
分块检视大体量结果
FEATURE STATE: Kubernetes v1.9 [beta]
在较大规模的集群中,检视某些资源类型的集合时可能会返回较大体量的响应数据,对
服务器和客户端都会造成影响。例如,某集群可能包含数万个 Pod,每个 Pod 的 JSON
编码都有 1-2 KB 的大小。返回所有名字空间的全部 Pod 时,其结果可能体量很大
(10-20 MB)且耗用大量的服务器资源。
从 Kubernetes 1.9 开始,服务器支持将单一的大体量集合请求分解成多个小数据块
同时还保证整个请求的一致性的能力。
各个数据块可以按顺序返回,进而降低请求的尺寸,允许面向用户的客户端以增量形式
呈现返回结果,改进系统响应效果。
为了用分块的形式返回一个列表,集合请求上可以设置两个新的参数 limit
和
continue
,并且所有 list 操作的返回结果列表的 metadata
字段中会包含一个
新的 continue
字段。
客户端应该将 limit
设置为希望在每个数据块中收到的结果个数上限,而服务器则
会在结果中至多返回 limit
个资源并在集合中还有更多资源的时候包含一个
continue
值。客户端在下次请求时则可以将此 continue
值传递给服务器,
告知后者要从何处开始返回结果的下一个数据块。
通过重复这一操作直到服务器端返回空的 continue
值,客户端可以受到结果的
全集。
与 watch 操作类似,continue
令牌也会在很短的时间(默认为 5 分钟)内过期,
并在无法返回更多结果时返回 410 Gone
代码。
这时,客户端需要从头开始执行上述检视操作或者忽略 limit
参数。
例如,如果集群上有 1253 个 Pods,客户端希望每次收到包含至多 500 个 Pod 的
数据块,它应按下面的步骤来请求数据块:
列举集群中所有 Pod,每次接收至多 500 个 Pods:
GET /api/v1/pods?limit=500
---
200 OK
Content-Type: application/json
{
"kind": "PodList",
"apiVersion": "v1",
"metadata": {
"resourceVersion":"10245",
"continue": "ENCODED_CONTINUE_TOKEN",
...
},
"items": [...] // returns pods 1-500
}
继续前面的调用,返回下一组 500 个 Pods:
GET /api/v1/pods?limit=500&continue=ENCODED_CONTINUE_TOKEN
---
200 OK
Content-Type: application/json
{
"kind": "PodList",
"apiVersion": "v1",
"metadata": {
"resourceVersion":"10245",
"continue": "ENCODED_CONTINUE_TOKEN_2",
...
},
"items": [...] // returns pods 501-1000
}
继续前面的调用,返回最后 253 个 Pods:
GET /api/v1/pods?limit=500&continue=ENCODED_CONTINUE_TOKEN_2
---
200 OK
Content-Type: application/json
{
"kind": "PodList",
"apiVersion": "v1",
"metadata": {
"resourceVersion":"10245",
"continue": "", // continue token is empty because we have reached the end of the list
...
},
"items": [...] // returns pods 1001-1253
}
注意 list 操作的 resourceVersion
在每个请求中都设置的是同一个数值,
这表明服务器要向我们展示一个一致的 Pods 快照视图。
在版本 10245
之后创建、更新或删除的 Pods 都不会显示出来,除非用户发出
list 请求时不指定 continue
令牌。
这一设计使得客户端能够将较大的响应切分为较小的数据块,且能够对较大的集合
执行监视动作而不会错失任何更新事件。
以表格形式接收资源
kubectl get
命令的输出是一个包含一个或多个资源的简单表格形式。
过去,客户端需要重复 kubectl
中所实现的表格输出和描述输出逻辑,以执行
简单的对象列表操作。
这一方法在处理某些对象时,需要引入不容忽视的逻辑。
此外,API 聚合
和定制资源
所提供的资源类型都是编译时不可预知的。这意味着,客户端必须针对无法
识别的类型提供通用的实现逻辑。
为了避免上述各种潜在的局限性,客户端可以请求服务器端返回对象的表格(Table)
表现形式,从而将打印输出的特定细节委托给服务器。
Kubernetes API 实现标准的 HTTP 内容类型(Content Type)协商:为 GET
调用
传入一个值为 application/json;as=Table;g=meta.k8s.io;v=v1beta1
的 Accept
头部即可请求服务器以 Table 的内容类型返回对象。
例如,以 Table 格式列举集群中所有 Pods:
GET /api/v1/pods
Accept: application/json;as=Table;g=meta.k8s.io;v=v1beta1
---
200 OK
Content-Type: application/json
{
"kind": "Table",
"apiVersion": "meta.k8s.io/v1beta1",
...
"columnDefinitions": [
...
]
}
对于在服务器上不存在定制的 Table 定义的 API 资源类型而言,服务器会返回
一个默认的 Table 响应,其中包含资源的 name
和 creationTimestamp
字段。
GET /apis/crd.example.com/v1alpha1/namespaces/default/resources
---
200 OK
Content-Type: application/json
...
{
"kind": "Table",
"apiVersion": "meta.k8s.io/v1beta1",
...
"columnDefinitions": [
{
"name": "Name",
"type": "string",
...
},
{
"name": "Created At",
"type": "date",
...
}
]
}
kube-apiserver
从 1.10 版本开始提供 Table 响应。
因此,并非所有 API 资源类型都支持 Table 响应,尤其是使用客户端访问较老的集群时。
如果客户端需要能够处理所有资源类型,或者有可能需要与较老的集群交互,
则需要在其 Accept
头部设定多个内容类型值,以便可以回退到非表格形式的 JSON
表示。
Accept: application/json;as=Table;g=meta.k8s.io;v=v1beta1, application/json
资源的其他表示形式
默认情况下,Kubernetes 返回 JSON 序列化的的对象并设定内容类型为
application/json
。这是 API 的默认序列化格式。
不过,客户端也可出于大规模环境中更佳性能的需求而请求对象的更为高效的 Protobuf
表现形式。
Kubernetes API 实现了标准的 HTTP 内容类型协商:为 GET
调用传递一个 Accept
头部来请求服务器以所指定的内容类型返回对象,同时在通过 PUT
或 POST
调用
向服务器发送 Protobuf 格式的对象时提供 Content-Type
头部。
服务器会能够支持所请求的格式时返回 Content-Type
头部,并在所提供的内容类型
不合法时返回 406 Not acceptable(无法接受)
错误。
请参阅 API 文档了解每个 API 所支持的内容类型。
例如:
以 Protobuf 格式列举集群上的所有 Pods:
GET /api/v1/pods
Accept: application/vnd.kubernetes.protobuf
---
200 OK
Content-Type: application/vnd.kubernetes.protobuf
... binary encoded PodList object
通过向服务器发送 Protobuf 编码的数据创建 Pod,但请求以 JSON 形式接收响应:
POST /api/v1/namespaces/test/pods
Content-Type: application/vnd.kubernetes.protobuf
Accept: application/json
... binary encoded Pod object
---
200 OK
Content-Type: application/json
{
"kind": "Pod",
"apiVersion": "v1",
...
}
并非所有 API 资源类型都支持 Protobuf,尤其是那些通过定制资源定义(CRD)或通过
API 扩展而加入的资源。如果客户端必须能够处理所有资源类型,则应在其 Accept
头部指定多种内容类型以便可以回退到 JSON 格式:
Accept: application/vnd.kubernetes.protobuf, application/json
Protobuf encoding
Kubernetes 使用封套形式来对 Protobuf 响应进行编码。
封套外层由 4 个字节的特殊数字开头,便于从磁盘文件或 etcd 中辩识 Protobuf
格式的(而不是 JSON)数据。
接下来存放的是 Protobuf 编码的封套消息,其中描述下层对象的编码和类型,最后
才是对象本身。
封套格式如下:
四个字节的特殊数字前缀:
字节 0-3: "k8s\x00" [0x6b, 0x38, 0x73, 0x00]
使用下面 IDL 来编码的 Protobuf 消息:
message Unknown {
// typeMeta 应该包含 "kind" 和 "apiVersion" 的字符串值,就像
// 对应的 JSON 对象中所设置的那样
optional TypeMeta typeMeta = 1;
// raw 中将保存用 protobuf 序列化的完整对象。
// 参阅客户端库中为指定 kind 所作的 protobuf 定义
optional bytes raw = 2;
// contentEncoding 用于 raw 数据的编码格式。未设置此值意味着没有特殊编码。
optional string contentEncoding = 3;
// contentType 包含 raw 数据所采用的序列化方法。
// 未设置此值意味着 application/vnd.kubernetes.protobuf,且通常被忽略
optional string contentType = 4;
}
message TypeMeta {
// apiVersion 是 type 对应的组名/版本
optional string apiVersion = 1;
// kind 是对象模式定义的名称。此对象应该存在一个 protobuf 定义。
optional string kind = 2;
}
收到 application/vnd.kubernetes.protobuf
格式响应的客户端在响应与预期的前缀
不匹配时应该拒绝响应,因为将来的版本可能需要以某种不兼容的方式更改序列化格式,
并且这种更改是通过变更前缀完成的。
资源删除
资源删除要经过两个阶段:1) 终止(finalization),和 2)去除。
{
"kind" : "ConfigMap" ,
"apiVersion" : "v1" ,
"metadata" : {
"finalizers" : {"url.io/neat-finalization" , "other-url.io/my-finalizer" },
"deletionTimestamp" : nil ,
}
}
当客户端首先删除某资源时,其 .metadata.deletionTimestamp
会被设置为当前时间。
一旦 .metadata.deletionTimestamp
被设置,则对终结器(finalizers)执行动作
的外部控制器就可以在任何时候、以任何顺序执行其清理工作。
这里不强调顺序是因为很可能带来 .metadata.finalizers
被锁定的风险。
.metadata.finalizers
是一个共享的字段,任何具有相关权限的主体都可以对其
执行重排序的操作。如果终结器列表要按顺序处理,则很可能导致负责列表中第一个
终结器的组件要等待负责列表中排序靠后的终结器的组件的信号(可能是字段值变更、
外部系统或者其他形式),从而导致死锁行为。
在不对终结器顺序作强制要求的情况下,终结器可以自行排序,且不会因为其在列表
中的顺序而引入任何不稳定因素。
当最后一个终结器也被移除时,资源才真正从 etcd 中移除。
单个资源 API
API 动词 GET、CREATE、UPDATE、PATCH、DELETE 和 PROXY 仅支持单个资源。
这些支持单一资源的动词不支持以有序或无序列表甚或事务的形式同时提交给
多个资源。
包括 kubectl 在内的客户端将解析资源的列表,并执行单一资源的 API 请求。
API 动词 LIST 和 WATCH 支持获取多个资源,而 DELETECOLLECTION 支持删除多个
资源。
试运行
FEATURE STATE: Kubernetes v1.18 [stable]
修改性质的动词(POST
、PUT
、PATCH
和 DELETE
)可以支持 试运行(dry
run) 模式的请求。试运行模式可帮助通过典型的请求阶段(准入控制链、合法性
检查、合并冲突)来评估请求,只是最终的对象不会写入存储。请求的响应主体与
非试运行模式下的响应尽可能接近。系统会保证试运行模式的请求不会被写入到存储
中,也不会产生其他副作用。
发起试运行请求
通过设置 dryRun
查询参数可以触发试运行模式。此参数是一个字符串,以枚举值
的形式工作且可接受的值只有:
例如:
POST /api/v1/namespaces/test/pods?dryRun=All
Content-Type: application/json
Accept: application/json
响应会与非试运行模式请求的响应看起来相同,只是某些生成字段的值可能会不同。
试运行的授权
试运行和非试运行请求的鉴权是完全相同的。因此,要发起一个试运行请求,用户必须
被授权执行非试运行请求。
例如,要在 Deployment 对象上试运行 PATCH
操作,你必须具有对 Deployment 执行
PATCH
操作的访问权限,如下面的 RBAC 规则所示:
rules :
- apiGroups : ["extensions" , "apps" ]
resources : ["deployments" ]
verbs : ["patch" ]
参阅鉴权概述 以了解鉴权细节。
生成的值
对象的某些值通常是在对象被写入数据库之前生成的。很重要的一点是不要依赖试运行
请求为这些字段所设置的值,因为试运行模式下所得到的这些值与真实请求所获得的
值很可能不同。这类字段有:
name
:如果设置了 generateName
字段,则 name
会获得一个唯一的随机名称
creationTimestamp
/deletionTimestamp
:记录对象的创建/删除时间
UID
:唯一性标识对象,取值随机生成(非确定性)
resourceVersion
: 跟踪对象的持久化(存储)版本
变更性准入控制器所设置的字段
对于 Service
资源:kube-apiserver
为 v1.Service
对象分配的端口和 IP
服务器端应用
FEATURE STATE: Kubernetes v1.16 [beta]
从 Kubernetes v1.18 开始,可以启用服务器端应用 功能
特性,启用该特性后,控制面会跟踪所有新创建的对象的托管字段。服务器端应用提供了一种简洁的模式来管理字段冲突,提供服务器端的 Apply
和 Update
操作,并取代了
kubectl apply
的客户端功能。有关该特性的详细描述,请参见服务器端应用 章节
资源版本
资源版本采用字符串来表达,用来标示对象的服务器端内部版本。
客户端可以使用资源版本来判定对象是否被更改,或者在读取、列举或监视资源时
用来表达数据一致性需求。
客户端必需将资源版本视为不透明的对象,将其原封不动地传递回服务器端。
例如,客户端一定不能假定资源版本是某种数值标识,也不可以对两个资源版本值
进行比较看其是否相同(也就是不可以比较两个版本值以判断其中一个比另一个
大或小)。
客户端可以在资源中看到资源版本信息,这里的资源包括从服务器返回的 Watch 事件
以及 list 操作响应:
v1.meta/ObjectMeta - 资源
的 metadata.resourceVersion
值标明该实例上次被更改时的资源版本。
v1.meta/ListMeta - 资源集合
(即 list 操作的响应)的 metadata.resourceVersion
所标明的是 list 响应被构造
时的资源版本。
resourceVersion
参数
GET、LIST 和 WATCH 操作都支持 resourceVersion
参数。
参数的具体含义取决于所执行的操作和所给的 resourceVersion
值:
对于 GET 和 LIST 而言,资源版本的语义为:
GET:
resourceVersion 未设置
resourceVersion="0"
resourceVersion="<非零值>"
最新版本
任何版本
不老于给定版本
LIST:
v1.19 及以上版本的 API 服务器支持 resourceVersionMatch
参数,用以确定如何对
LIST 调用应用 resourceVersion 值。
强烈建议在为 LIST 调用设置了 resourceVersion
时也设置 resourceVersionMatch
。
如果 resourceVersion
未设置,则 resourceVersionMatch
是不允许设置的。
为了向后兼容,客户端必须能够容忍服务器在某些场景下忽略 resourceVersionMatch
的行为:
当设置 resourceVersionMatch=NotOlderThan
且指定了 limit
时,客户端必须能够
处理 HTTP 410 "Gone" 响应。例如,客户端可以使用更新一点的 resourceVersion
来重试,或者回退到 resourceVersion=""
(即允许返回任何版本)。
当设置了 resourceVersionMatch=Exact
且未指定 limit
时,客户端必须验证
响应数据中 ListMeta
的 resourceVersion
与所请求的 resourceVersion
匹配,
并处理二者可能不匹配的情况。例如,客户端可以重试设置了 limit
的请求。
除非你对一致性有着非常强烈的需求,使用 resourceVersionMatch=NotOlderThan
同时为 resourceVersion
设定一个已知值是优选的交互方式,因为与不设置
resourceVersion
和 resourceVersionMatch
相比,这种配置可以取得更好的
集群性能和可扩缩性。后者需要提供带票选能力的读操作。
list 操作的 resourceVersionMatch 与分页参数
resourceVersionMatch 参数
分页参数
resourceVersion 未设置
resourceVersion="0"
resourceVersion="<非零值>"
resourceVersionMatch 未设置
limit 未设置
最新版本
任意版本
不老于指定版本
resourceVersionMatch 未设置
limit=<n>, continue 未设置
最新版本
任意版本
精确匹配
resourceVersionMatch 未设置
limit=<n>, continue=<token>
从 token 开始、精确匹配
非法请求,视为从 token 开始、精确匹配
非法请求,返回 HTTP 400 Bad Request
resourceVersionMatch=Exact [1]
limit 未设置
非法请求
非法请求
精确匹配
resourceVersionMatch=Exact [1]
limit=<n>, continue 未设置
非法请求
非法请求
精确匹配
resourceVersionMatch=NotOlderThan [1]
limit 未设置
非法请求
任意版本
不老于指定版本
resourceVersionMatch=NotOlderThan [1]
limit=<n>, continue 未设置
非法请求
任意版本
不老于指定版本
脚注:
[1] 如果服务器无法正确处理 resourceVersionMatch
参数,其行为与未设置该参数相同。
GET 和 LIST 操作的语义含义如下:
最新版本: 返回资源版本为最新的数据。所返回的数据必须一致
(通过票选读操作从 etcd 中取出)。
任意版本: 返回任意资源版本的数据。优选最新可用的资源版本,不过不能保证
强一致性;返回的数据可能是任何资源版本的。请求返回的数据有可能是客户端以前
看到过的很老的资源版本。尤其在某些高可用配置环境中,网络分区或者高速缓存
未被更新等状态都可能导致这种状况。不能容忍这种不一致性的客户端不应采用此
语义。
不老于指定版本: 返回至少比所提供的 resourceVersion
还要新的数据。
优选最新的可用数据,不过最终提供的可能是不老于所给 resourceVersion
的任何版本。
对于发给能够正确处理 resourceVersionMatch
参数的服务器的 LIST 请求,此语义
保证 ListMeta
中的 resourceVersion
不老于请求的 resourceVersion
,不过
不对列表条目之 ObjectMeta
的 resourceVersion
提供任何保证。
这是因为 ObjectMeta.resourceVersion
所跟踪的是列表条目对象上次更新的时间,
而不是对象被返回时是否是最新。
确定版本: 返回精确匹配所给资源版本的数据。如果所指定的 resourceVersion
的数据不可用,服务器会响应 HTTP 410 "Gone"。
对于发送给能够正确处理 resourceVersionMatch
参数的服务器的 LIST 请求而言,
此语义会保证 ListMeta 中的 resourceVersion
与所请求的 resourceVersion
匹配, 不过不对列表条目之 ObjectMeta
的 resourceVersion
提供任何保证。
这是因为 ObjectMeta.resourceVersion
所跟踪的是列表条目对象上次更新的时间,
而不是对象被返回时是否是最新。
Continue 令牌、精确匹配: 返回原先带分页参数的 LIST 调用中指定的资源版本的数据。
在最初的带分页参数的 LIST 调用之后,所有分页式的 LIST 调用都使用所返回的 Continue
令牌来跟踪最初提供的资源版本,
对于 WATCH 操作而言,资源版本的语义如下:
WATCH:
watch 操作的 resourceVersion 设置
resourceVersion 未设置
resourceVersion="0"
resourceVersion="<非零值>"
读取状态并从最新版本开始
读取状态并从任意版本开始
从指定版本开始
WATCH 操作语义的含义如下:
读取状态并从最新版本开始: 从最新的资源版本开始 WATCH 操作。这里的
最新版本必须是一致的(即通过票选读操作从 etcd 中取出)。为了建立初始状态,
WATCH 首先会处理一组合成的 "Added" 事件,这些事件涵盖在初始资源版本中存在
的所有资源实例。
所有后续的 WATCH 事件都是关于 WATCH 开始时所处资源版本之后发生的变更。
读取状态并从任意版本开始: 警告:通过这种方式初始化的 WATCH 操作可能会
返回任何状态的停滞数据。请在使用此语义之前执行复核,并在可能的情况下采用其他
语义。此语义会从任意资源版本开始执行 WATCH 操作,优选最新的可用的资源版本,
不过不是必须的;采用任何资源版本作为起始版本都是被允许的。
WATCH 操作有可能起始于客户端已经观测到的很老的版本。在高可用配置环境中,因为
网络分裂或者高速缓存未及时更新的原因都会造成此现象。
如果客户端不能容忍这种不一致性,就不要使用此语义来启动 WATCH 操作。
为了建立初始状态,WATCH 首先会处理一组合成的 "Added" 事件,这些事件涵盖在
初始资源版本中存在的所有资源实例。
所有后续的 WATCH 事件都是关于 WATCH 开始时所处资源版本之后发生的变更。
从指定版本开始: 从某确切资源版本开始执行 WATCH 操作。WATCH 事件都是
关于 WATCH 开始时所处资源版本之后发生的变更。与前面两种语义不同,WATCH 操作
开始的时候不会生成或处理为所提供资源版本合成的 "Added" 事件。
我们假定客户端既然能够提供确切资源版本,就应该已经拥有了起始资源版本对应的初始状态。
"410 Gone" 响应
服务器不需要提供所有老的资源版本,在客户端请求的是早于服务器端所保留版本的
resourceVersion
时,可以返回 HTTP 410 (Gone)
状态码。
客户端必须能够容忍 410 (Gone)
响应。
参阅高效检测变更 以了解如何在监测资源时
处理 410 (Gone)
响应。
如果所请求的 resourceVersion
超出了可应用的 limit
,那么取决于请求是否
是通过高速缓存来满足的,API 服务器可能会返回一个 410 Gone
HTTP 响应。
不可用的资源版本
服务器不必未无法识别的资源版本提供服务。针对无法识别的资源版本的 LIST 和 GET 请求
可能会短暂等待,以期资源版本可用。如果所给的资源版本在一定的时间段内仍未变得
可用,服务器应该超时并返回 504 (Gateway Timeout)
,且可在响应中添加
Retry-After
响应头部字段,标明客户端在再次尝试之前应该等待多少秒钟。
目前,kube-apiserver
也能使用 Too large resource version(资源版本过高)
消息来标识这类响应。针对某无法识别的资源版本的 WATCH 操作可能会无限期
(直到请求超时)地等待下去,直到资源版本可用。
2.2 - 服务器端应用(Server-Side Apply)
FEATURE STATE: Kubernetes v1.22 [stable]
简介
服务器端应用协助用户、控制器通过声明式配置的方式管理他们的资源。
客户端可以发送完整描述的目标(A fully specified intent),
声明式地创建和/或修改
对象 。
一个完整描述的目标并不是一个完整的对象,仅包括能体现用户意图的字段和值。
该目标(intent)可以用来创建一个新对象,
也可以通过服务器来实现与现有对象的合并 。
系统支持多个应用者(appliers)在同一个对象上开展协作。
“字段管理(field management) ”机制追踪对象字段的变化。
当一个字段值改变时,其所有权从当前管理器(manager)转移到施加变更的管理器。
当尝试将新配置应用到一个对象时,如果字段有不同的值,且由其他管理器管理,
将会引发冲突 。
冲突引发警告信号:此操作可能抹掉其他协作者的修改。
冲突可以被刻意忽略,这种情况下,值将会被改写,所有权也会发生转移。
当你从配置文件中删除一个字段,然后应用这个配置文件,
这将触发服务端应用检查此字段是否还被其他字段管理器拥有。
如果没有,那就从活动对象中删除该字段;如果有,那就重置为默认值。
该规则同样适用于 list 或 map 项目。
服务器端应用既是原有 kubectl apply
的替代品,
也是控制器发布自身变化的一个简化机制。
如果你启用了服务器端应用,控制平面就会跟踪被所有新创建对象管理的字段。
字段管理
相对于通过 kubectl
管理的注解 last-applied
,
服务器端应用使用了一种更具声明式特点的方法:
它持续的跟踪用户的字段管理,而不仅仅是最后一次的执行状态。
这就意味着,作为服务器端应用的一个副作用,
关于用哪一个字段管理器负责管理对象中的哪个字段的这类信息,都要对外界开放了。
用户管理字段这件事,在服务器端应用的场景中,意味着用户依赖并期望字段的值不要改变。
最后一次对字段值做出断言的用户将被记录到当前字段管理器。
这可以通过发送 POST
、 PUT
、
或非应用(non-apply)方式的 PATCH
等命令来修改字段值的方式实现,
或通过把字段放在配置文件中,然后发送到服务器端应用的服务端点的方式实现。
当使用服务器端应用,尝试着去改变一个被其他人管理的字段,
会导致请求被拒绝(在没有设置强制执行时,参见冲突 )。
如果两个或以上的应用者均把同一个字段设置为相同值,他们将共享此字段的所有权。
后续任何改变共享字段值的尝试,不管由那个应用者发起,都会导致冲突。
共享字段的所有者可以放弃字段的所有权,这只需从配置文件中删除该字段即可。
字段管理的信息存储在 managedFields
字段中,该字段是对象的
metadata
中的一部分。
服务器端应用创建对象的简单示例如下:
apiVersion : v1
kind : ConfigMap
metadata :
name : test-cm
namespace : default
labels :
test-label : test
managedFields :
- manager : kubectl
operation : Apply
apiVersion : v1
time : "2010-10-10T0:00:00Z"
fieldsType : FieldsV1
fieldsV1 :
f:metadata :
f:labels :
f:test-label : {}
f:data :
f:key : {}
data :
key : some value
上述对象在 metadata.managedFields
中包含了唯一的管理器。
管理器由管理实体自身的基本信息组成,比如操作类型、API 版本、以及它管理的字段。
说明: 该字段由 API 服务器管理,用户不应该改动它。
不过,执行 Update
操作修改 metadata.managedFields
也是可实现的。
强烈不鼓励这么做,但当发生如下情况时,
比如 managedFields
进入不一致的状态(显然不应该发生这种情况),
这么做也是一个合理的尝试。
managedFields
的格式在
API
文档中描述。
冲突
冲突是一种特定的错误状态,
发生在执行 Apply
改变一个字段,而恰巧该字段被其他用户声明过主权时。
这可以防止一个应用者不小心覆盖掉其他用户设置的值。
冲突发生时,应用者有三种办法来解决它:
覆盖前值,成为唯一的管理器: 如果打算覆盖该值(或应用者是一个自动化部件,比如控制器),
应用者应该设置查询参数 force
为 true,然后再发送一次请求。
这将强制操作成功,改变字段的值,从所有其他管理器的 managedFields 条目中删除指定字段。
不覆盖前值,放弃管理权: 如果应用者不再关注该字段的值,
可以从配置文件中删掉它,再重新发送请求。
这就保持了原值不变,并从 managedFields 的应用者条目中删除该字段。
不覆盖前值,成为共享的管理器: 如果应用者仍然关注字段值,并不想覆盖它,
他们可以在配置文件中把字段的值改为和服务器对象一样,再重新发送请求。
这样在不改变字段值的前提下,
就实现了字段管理被应用者和所有声明了管理权的其他的字段管理器共享。
管理器
管理器识别出正在修改对象的工作流程(在冲突时尤其有用),
管理器可以通过修改请求的参数 fieldManager
指定。
虽然 kubectl 默认发往 kubectl
服务端点,但它则请求到应用的服务端点(apply endpoint)。
对于其他的更新,它默认的是从用户代理计算得来。
应用和更新
此特性涉及两类操作,分别是 Apply
(内容类型为 application/apply-patch+yaml
的 PATCH
请求)
和 Update
(所有修改对象的其他操作)。
这两类操作都会更新字段 managedFields
,但行为表现有一点不同。
说明: 不管你提交的是 JSON 数据还是 YAML 数据,
都要使用 application/apply-patch+yaml
作为 Content-Type
的值。
所有的 JSON 文档 都是合法的 YAML。
例如,在冲突发生的时候,只有 apply
操作失败,而 update
则不会。
此外,apply
操作必须通过提供一个 fieldManager
查询参数来标识自身,
而此查询参数对于 update
操作则是可选的。
最后,当使用 apply
命令时,你不能在应用中的对象中持有 managedFields
。
一个包含多个管理器的对象,示例如下:
apiVersion : v1
kind : ConfigMap
metadata :
name : test-cm
namespace : default
labels :
test-label : test
managedFields :
- manager : kubectl
operation : Apply
apiVersion : v1
fields :
f:metadata :
f:labels :
f:test-label : {}
- manager : kube-controller-manager
operation : Update
apiVersion : v1
time : '2019-03-30T16:00:00.000Z'
fields :
f:data :
f:key : {}
data :
key : new value
在这个例子中,
第二个操作被管理器 kube-controller-manager
以 Update
的方式运行。
此 update
更改 data 字段的值,
并使得字段管理器被改为 kube-controller-manager
。
如果把 update
操作改为 Apply
,那就会因为所有权冲突的原因,导致操作失败。
合并策略
由服务器端应用实现的合并策略,提供了一个总体更稳定的对象生命周期。
服务器端应用试图依据负责管理它们的主体来合并字段,而不是根据值来否决。
这么做是为了多个主体可以更新同一个对象,且不会引起意外的相互干扰。
当用户发送一个“完整描述的目标”对象到服务器端应用的服务端点,
服务器会将它和活动对象做一次合并,如果两者中有重复定义的值,那就以配置文件的为准。
如果配置文件中的项目集合不是此用户上一次操作项目的超集,
所有缺少的、没有其他应用者管理的项目会被删除。
关于合并时用来做决策的对象规格的更多信息,参见
sigs.k8s.io/structured-merge-diff .
Kubernetes 1.16 和 1.17 中添加了一些标记,
允许 API 开发人员描述由 list、map、和 structs 支持的合并策略。
这些标记可应用到相应类型的对象,在 Go 文件或在
CRD
的 OpenAPI 的模式中定义:
Golang 标记
OpenAPI extension
可接受的值
描述
引入版本
//+listType
x-kubernetes-list-type
atomic
/set
/map
适用于 list。set
适用于仅包含标量元素的列表。这些元素必须是不重复的。map
仅适用于包含嵌套类型的列表。列表中的键(参见 listMapKey
)不可以重复。atomic
适用于任何类型的列表。如果配置为 atomic
,则合并时整个列表会被替换掉。任何时候,只有一个管理器负责管理指定列表。如果配置为 set
或 map
,不同的管理器也可以分开管理条目。
1.16
//+listMapKey
x-kubernetes-list-map-keys
字段名称的列表,例如,["port", "protocol"]
仅当 +listType=map
时适用。取值为字段名称的列表,这些字段值的组合能够唯一标识列表中的条目。尽管可以存在多个键,listMapKey
是单数的,这是因为键名需要在 Go 类型中各自独立指定。键字段必须是标量。
1.16
//+mapType
x-kubernetes-map-type
atomic
/granular
适用于 map。 atomic
指 map 只能被单个的管理器整个的替换。 granular
指 map 支持多个管理器各自更新自己的字段。
1.17
//+structType
x-kubernetes-map-type
atomic
/granular
适用于 structs;否则就像 //+mapType
有相同的用法和 openapi 注释.
1.17
若未指定 listType
,API 服务器将 patchMergeStrategy=merge
标记解释为
listType=map
并且视对应的 patchMergeKey
标记为 listMapKey
取值。
atomic
列表类型是递归的。
这些标记都是用源代码注释的方式给出的,不必作为字段标签(tag)再重复。
拓扑变化时的兼容性
在极少的情况下,CRD 或者内置类型的作者可能希望更改其资源中的某个字段的
拓扑配置,同时又不提升版本号。
通过升级集群或者更新 CRD 来更改类型的拓扑信息与更新现有对象的结果不同。
变更的类型有两种:一种是将字段从 map
/set
/granular
更改为 atomic
,
另一种是做逆向改变。
当 listType
、mapType
或 structType
从 map
/set
/granular
改为
atomic
时,现有对象的整个列表、映射或结构的属主都会变为这些类型的
元素之一的属主。这意味着,对这些对象的进一步变更会引发冲突。
当一个列表、映射或结构从 atomic
改为 map
/set
/granular
之一
时,API 服务器无法推导这些字段的新的属主。因此,当对象的这些字段
再次被更新时不会引发冲突。出于这一原因,不建议将某类型从 atomic
改为
map
/set
/granular
。
以下面的自定义资源为例:
apiVersion : example.com/v1
kind : Foo
metadata :
name : foo-sample
managedFields :
- manager : manager-one
operation : Apply
apiVersion : example.com/v1
fields :
f:spec :
f:data : {}
spec :
data :
key1 : val1
key2 : val2
在 spec.data
从 atomic
改为 granular
之前,manager-one
是
spec.data
字段及其所包含字段(key1
和 key2
)的属主。
当对应的 CRD 被更改,使得 spec.data
变为 granular
拓扑时,
manager-one
继续拥有顶层字段 spec.data
(这意味着其他管理者想
删除名为 data
的映射而不引起冲突是不可能的),但不再拥有
key1
和 key2
。因此,其他管理者可以在不引起冲突的情况下更改
或删除这些字段。
自定义资源
默认情况下,服务器端应用把自定义资源看做非结构化数据。
所有的键值(keys)就像 struct 的字段一样被处理,
所有的 list 被认为是原子性的。
如果自定义资源定义(Custom Resource Definition,CRD)定义了一个
模式 ,
它包含类似以前“合并策略”章节中定义过的注解,
这些注解将在合并此类型的对象时使用。
在控制器中使用服务器端应用
控制器的开发人员可以把服务器端应用作为简化控制器的更新逻辑的方式。
读-改-写 和/或 patch 的主要区别如下所示:
应用的对象必须包含控制器关注的所有字段。
对于在控制器没有执行过应用操作之前就已经存在的字段,不能删除。
(控制器在这种用例环境下,依然可以发送一个 PATCH/UPDATE)
对象不必事先读取,resourceVersion
不必指定。
强烈推荐:设置控制器在冲突时强制执行,这是因为冲突发生时,它们没有其他解决方案或措施。
转移所有权
除了通过冲突解决方案 提供的并发控制,
服务器端应用提供了一些协作方式来将字段所有权从用户转移到控制器。
最好通过例子来说明这一点。
让我们来看看,在使用 HorizontalPodAutoscaler 资源和与之配套的控制器,
且开启了 Deployment 的自动水平扩展功能之后,
怎么安全的将 replicas
字段的所有权从用户转移到控制器。
假设用户定义了 Deployment,且 replicas
字段已经设置为期望的值:
apiVersion : apps/v1
kind : Deployment
metadata :
name : nginx-deployment
labels :
app : nginx
spec :
replicas : 3
selector :
matchLabels :
app : nginx
template :
metadata :
labels :
app : nginx
spec :
containers :
- name : nginx
image : nginx:1.14.2
并且,用户使用服务器端应用,像这样创建 Deployment:
kubectl apply -f https://k8s.io/examples/application/ssa/nginx-deployment.yaml --server-side
然后,为 Deployment 启用 HPA,例如:
kubectl autoscale deployment nginx-deployment --cpu-percent= 50 --min= 1 --max= 10
现在,用户希望从他们的配置中删除 replicas
,所以他们总是和 HPA 控制器冲突。
然而,这里存在一个竟态:
在 HPA 需要调整 replicas
之前会有一个时间窗口,
如果在 HPA 写入字段成为所有者之前,用户删除了replicas
,
那 API 服务器就会把 replicas
的值设为 1, 也就是默认值。
这不是用户希望发生的事情,即使是暂时的。
这里有两个解决方案:
(基本操作)把 replicas
留在配置文件中;当 HPA 最终写入那个字段,
系统基于此事件告诉用户:冲突发生了。在这个时间点,可以安全的删除配置文件。
(高级操作)然而,如果用户不想等待,比如他们想为合作伙伴保持集群清晰,
那他们就可以执行以下步骤,安全的从配置文件中删除 replicas
。
首先,用户新定义一个只包含 replicas
字段的配置文件:
apiVersion : apps/v1
kind : Deployment
metadata :
name : nginx-deployment
spec :
replicas : 3
用户使用名为 handover-to-hpa
的字段管理器,应用此配置文件。
kubectl apply -f https://k8s.io/examples/application/ssa/nginx-deployment-replicas-only.yaml \
--server-side --field-manager= handover-to-hpa \
--validate= false
如果应用操作和 HPA 控制器产生冲突,那什么都不做。
冲突表明控制器在更早的流程中已经对字段声明过所有权。
在此时间点,用户可以从配置文件中删除 replicas
。
apiVersion : apps/v1
kind : Deployment
metadata :
name : nginx-deployment
labels :
app : nginx
spec :
selector :
matchLabels :
app : nginx
template :
metadata :
labels :
app : nginx
spec :
containers :
- name : nginx
image : nginx:1.14.2
注意,只要 HPA 控制器为 replicas
设置了一个新值,
该临时字段管理器将不再拥有任何字段,会被自动删除。
这里不需要执行清理工作。
在用户之间转移所有权
通过在配置文件中把一个字段设置为相同的值,用户可以在他们之间转移字段的所有权,
从而共享了字段的所有权。
当用户共享了字段的所有权,任何一个用户可以从他的配置文件中删除该字段,
并应用该变更,从而放弃所有权,并实现了所有权向其他用户的转移。
与客户端应用的对比
由服务器端应用实现的冲突检测和解决方案的一个结果就是,
应用者总是可以在本地状态中得到最新的字段值。
如果得不到最新值,下次执行应用操作时就会发生冲突。
解决冲突三个选项的任意一个都会保证:此应用过的配置文件是服务器上对象字段的最新子集。
这和客户端应用(Client Side Apply) 不同,如果有其他用户覆盖了此值,
过期的值被留在了应用者本地的配置文件中。
除非用户更新了特定字段,此字段才会准确,
应用者没有途径去了解下一次应用操作是否会覆盖其他用户的修改。
另一个区别是使用客户端应用的应用者不能改变他们正在使用的 API 版本,但服务器端应用支持这个场景。
从客户端应用升级到服务器端应用
客户端应用方式时,用户使用 kubectl apply
管理资源,
可以通过使用下面标记切换为使用服务器端应用。
kubectl apply --server-side [ --dry-run= server]
默认情况下,对象的字段管理从客户端应用方式迁移到 kubectl 触发的服务器端应用时,不会发生冲突。
注意: 保持注解 last-applied-configuration
是最新的。
从注解能推断出字段是由客户端应用管理的。
任何没有被客户端应用管理的字段将引发冲突。
举例说明,比如你在客户端应用之后,
使用 kubectl scale
去更新 replicas
字段,
可是该字段并没有被客户端应用所拥有,
在执行 kubectl apply --server-side
时就会产生冲突。
此操作以 kubectl
作为字段管理器来应用到服务器端应用。
作为例外,可以指定一个不同的、非默认字段管理器停止的这种行为,如下面的例子所示。
对于 kubectl 触发的服务器端应用,默认的字段管理器是 kubectl
。
kubectl apply --server-side --field-manager= my-manager [ --dry-run= server]
从服务器端应用降级到客户端应用
如果你用 kubectl apply --server-side
管理一个资源,
可以直接用 kubectl apply
命令将其降级为客户端应用。
降级之所以可行,这是因为 kubectl server-side apply
会保存最新的 last-applied-configuration
注解。
此操作以 kubectl
作为字段管理器应用到服务器端应用。
作为例外,可以指定一个不同的、非默认字段管理器停止这种行为,如下面的例子所示。
对于 kubectl 触发的服务器端应用,默认的字段管理器是 kubectl
。
kubectl apply --server-side --field-manager= my-manager [ --dry-run= server]
API 端点
启用了服务器端应用特性之后,
PATCH
服务端点接受额外的内容类型 application/apply-patch+yaml
。
服务器端应用的用户就可以把 YAMl 格式的
部分定义对象(partially specified objects)发送到此端点。
当一个配置文件被应用时,它应该包含所有体现你意图的字段。
清除 ManagedFields
可以从对象中剥离所有 managedField,
实现方法是通过使用 MergePatch
、 StrategicMergePatch
、
JSONPatch
、 Update
、以及所有的非应用方式的操作来覆盖它。
这可以通过用空条目覆盖 managedFields 字段的方式实现。以下是两个示例:
PATCH /api/v1/namespaces/default/configmaps/example-cm
Content-Type: application/merge-patch+json
Accept: application/json
Data: {"metadata":{"managedFields": [{}]}}
PATCH /api/v1/namespaces/default/configmaps/example-cm
Content-Type: application/json-patch+json
Accept: application/json
Data: [{"op": "replace", "path": "/metadata/managedFields", "value": [{}]}]
这一操作将用只包含一个空条目的列表覆写 managedFields,
来实现从对象中整个的去除 managedFields。
注意,只把 managedFields 设置为空列表并不会重置字段。
这么做是有目的的,所以 managedFields 将永远不会被与该字段无关的客户删除。
在重置操作结合 managedFields 以外其他字段更改的场景中,
将导致 managedFields 首先被重置,其他改变被押后处理。
其结果是,应用者取得了同一个请求中所有字段的所有权。
注意: 对于不接受资源对象类型的子资源(sub-resources),
服务器端应用不能正确地跟踪其所有权。
如果你对这样的子资源使用服务器端应用,变更的字段将不会被跟踪。
2.3 - 客户端库
本页面包含基于各种编程语言使用 Kubernetes API 的客户端库概述。
在使用 Kubernetes REST API 编写应用程序时,
您并不需要自己实现 API 调用和 “请求/响应” 类型。
您可以根据自己的编程语言需要选择使用合适的客户端库。
客户端库通常为您处理诸如身份验证之类的常见任务。
如果 API 客户端在 Kubernetes 集群中运行,大多数客户端库可以发现并使用 Kubernetes 服务帐户进行身份验证,
或者能够理解 kubeconfig 文件
格式来读取凭据和 API 服务器地址。
官方支持的 Kubernetes 客户端库
以下客户端库由 Kubernetes SIG API Machinery 正式维护。
社区维护的客户端库
说明:
本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循
CNCF 网站指南 ,按字母顺序列出项目。要将项目添加到此列表中,请在提交更改之前阅读
内容指南 。
以下 Kubernetes API 客户端库是由社区,而非 Kubernetes 团队支持、维护的。
2.4 - Kubernetes 弃用策略
本文档详细解释系统中各个层面的弃用策略(Deprecation Policy)。
Kubernetes 是一个组件众多、贡献者人数众多的大系统。
就像很多类似的软件,所提供的功能特性集合会随着时间推移而自然发生变化,
而且有时候某个功能特性可能需要被去除。被去除的可能是一个 API、一个参数标志或者
甚至某整个功能特性。为了避免影响到现有用户,Kubernetes 对于其中渐次移除
的各个方面规定了一种弃用策略并遵从此策略。
弃用 API 的一部分
由于 Kubernetes 是一个 API 驱动的系统,API 会随着时间推移而演化,以反映
人们对问题空间的认识的变化。Kubernetes API 实际上是一个 API 集合,其中每个
成员称作“API 组(API Group)”,并且每个 API 组都是独立管理版本的。
API 版本 会有
三类,每类有不同的废弃策略:
示例
分类
v1
正式发布(Generally available,GA,稳定版本)
v1beta1
Beta (预发布)
v1alpha1
Alpha (试验性)
给定的 Kubernetes 发布版本中可以支持任意数量的 API 组,且每组可以包含
任意个数的版本。
下面的规则负责指导 API 元素的弃用,具体元素包括:
REST 资源(也即 API 对象)
REST 资源的字段
REST 资源的注解,包含“beta”类注解但不包含“alpha”类注解
枚举值或者常数值
组件配置结构
以下是跨正式发布版本时要实施的规则,不适用于对 master 或发布分支上
不同提交之间的变化。
规则 #1:只能在增加 API 组版本号时删除 API 元素。
一旦在某个特定 API 组版本中添加了 API 元素,则该元素不可从该版本中删除,
且其行为也不能大幅度地变化,无论属于哪一类(GA、Alpha 或 Beta)。
说明: 由于历史原因,Kubernetes 中存在两个“单体式(Monolithic)”API 组 -
“core”(无组名)和“extensions”。这两个遗留 API 组中的资源会被逐渐迁移到
更为特定领域的 API 组中。
规则 #2:在给定的发布版本中,API 对象必须能够在不同的 API 版本之间来回
转换且不造成信息丢失,除非整个 REST 资源在某些版本中完全不存在。
例如,一个对象可被用 v1 来写入之后用 v2 来读出并转换为 v1,所得到的 v1 必须
与原来的 v1 对象完全相同。v2 中的表现形式可能与 v1 不同,但系统知道如何
在两个版本之间执行双向转换。
此外,v2 中添加的所有新字段都必须能够转换为 v1 再转换回来。这意味着 v1 必须
添加一个新的等效字段或者将其表现为一个注解。
规则 #3:给定类别的 API 版本在新的、稳定性未降低的 API 版本发布之前不可被废弃。
一个正式发布的(GA)API 版本可替换现有的正式 API 版本或 alpha、beta API 版本。
Beta API 版本 不可以 替代正式的 API 版本。
规则 #4a:除了每类 API 版本中的最新版本,旧的 API 版本在其被宣布被废弃之后
至少以下时长内仍需被支持:
GA:12 个月或者 3 个发布版本(取其较长者)
Beta: 9 个月或者 3 个发布版本(取其较长者)
Alpha: 0 个发布版本
这里也包含了关于最大支持 2 个发布版本的版本偏差
的约定。
说明: 在
#52185 被解决之前,
已经被保存到持久性存储中的 API 版本都不可以被去除。
你可以禁止这些版本所对应的 REST 末端(在符合本文中弃用时间线的前提下),
但是 API 服务器必须仍能解析和转换存储中以前写入的数据。
规则 #4b:标记为“preferred(优选的)” API 版本和给定 API 组的
“storage version(存储版本)”在既支持老版本也支持新版本的 Kubernetes 发布
版本出来以前不可以提升其版本号。
用户必须能够升级到 Kubernetes 新的发行版本,之后再回滚到前一个发行版本,且
整个过程中无需针对新的 API 版本做任何转换,也不允许出现功能损坏的情况,
除非用户显式地使用了仅在较新版本中才存在的功能特性。
就对象的存储表示而言,这一点尤其是不言自明的。
以上所有规则最好通过例子来说明。假定现有 Kubernetes 发行版本为 X,其中引入了
新的 API 组。大约每隔 4 个月会有一个新的 Kubernetes 版本被发布(每年 3 个版本)。
下面的表格描述了在一系列后续的发布版本中哪些 API 版本是受支持的。
发布版本
API 版本
优选/存储版本
注释
X
v1alpha1
v1alpha1
X+1
v1alpha2
v1alpha2
v1alpha1 被去除,发布说明中会包含 "action required(采取行动)" 说明
X+2
v1beta1
v1beta1
v1alpha2 被去除,发布说明中包含对应的 "action required(采取行动)" 说明
X+3
v1beta2、v1beta1(已弃用)
v1beta1
v1beta1 被弃用,发布说明中包含对应的 "action required(采取行动)" 说明
X+4
v1beta2、v1beta1(已弃用)
v1beta2
X+5
v1、v1beta1(已弃用)、v1beta2(已弃用)
v1beta2
v1beta2 被弃用,发布说明中包含对应的 "action required(采取行动)" 说明
X+6
v1、v1beta2(已弃用)
v1
v1beta1 被去除,发布说明中包含对应的 "action required(采取行动)" 说明
X+7
v1、v1beta2(已弃用)
v1
X+8
v2alpha1、v1
v1
v1beta2 被去除,发布说明中包含对应的 "action required(采取行动)" 说明
X+9
v2alpha2、v1
v1
v2alpha1 被删除,发布说明中包含对应的 "action required(采取行动)" 说明
X+10
v2beta1、v1
v1
v2alpha2 被删除,发布说明中包含对应的 "action required(采取行动)" 说明
X+11
v2beta2、v2beta1(已弃用)、v1
v1
v2beta1 被弃用,发布说明中包含对应的 "action required(采取行动)" 说明
X+12
v2、v2beta2(已弃用)、v2beta1(已弃用)、v1(已弃用)
v1
v2beta2 已被弃用,发布说明中包含对应的 "action required(采取行动)" 说明
v1 已被弃用,发布说明中包含对应的 "action required(采取行动)" 说明
X+13
v2、v2beta1(已弃用)、v2beta2(已弃用)、v1(已弃用)
v2
X+14
v2、v2beta2(已弃用)、v1(已弃用)
v2
v2beta1 被删除,发布说明中包含对应的 "action required(采取行动)" 说明
X+15
v2、v1(已弃用)
v2
v2beta2 被删除,发布说明中包含对应的 "action required(采取行动)" 说明
X+16
v2、v1(已弃用)
v2
X+17
v2
v2
v1 被删除,发布说明中包含对应的 "action required(采取行动)" 说明
REST 资源(也即 API 对象)
考虑一个假想的名为 Widget 的 REST 资源,在上述时间线中位于 API v1,
而现在打算将其弃用。
我们会在文档和
声明
中与 X+1 版本的发布同步记述此弃用决定。
Wdiget 资源仍会在 API 版本 v1(已弃用)中存在,但不会出现在 v2alpha1 中。
Widget 资源会 X+8 发布版本之前(含 X+8)一直存在并可用。
只有在发布版本 X+9 中,API v1 寿终正寝时,Widget
才彻底消失,相应的资源行为也被移除。
从 Kubernetes v1.19 开始,当 API 请求被发送到一个已弃用的 REST API 末端时:
API 响应中会包含一个 Warning
头部字段(如 RFC7234 5.5 节 所定义);
该请求会导致对应的
审计事件
中会增加一个注解 "k8s.io/deprecated":"true"
。
kube-apiserver
进程的 apiserver_requested_deprecated_apis
度量值会被
设置为 1
。
该度量值还附带 group
、version
、resource
和 subresource
标签
(可供添加到度量值 apiserver_request_total
上),
和一个 removed_release
标签,标明该 API 将消失的 Kubernetes 发布版本。
下面的 Prometheus 查询会返回对 v1.22 中将移除的、已弃用的 API
的请求的信息:
apiserver_requested_deprecated_apis {removed_release = "1.22 "} * on ( group ,version ,resource ,subresource ) group_right () apiserver_request_total
REST 资源的字段
就像整个 REST 资源一样,在 API v1 中曾经存在的各个字段在 API v1 被移除
之前必须一直存在且起作用。
与整个资源上的规定不同,v2 API 可以选择为字段提供不同的表示方式,
只要对应的资源对象可在不同版本之间来回转换即可。
例如,v1 版本中一个名为 "magnitude" 的已弃用字段可能在 API v2 中被命名
为 "deprecatedMagnitude"。当 v1 最终被移除时,废弃的字段也可以从 v2
中移除。
枚举值或常数值
就像前文讲述的 REST 资源及其中的单个字段一样,API v1 中所支持的常数值
必须在 API v1 被移除之前一直存在且起作用。
组件配置结构
组件的配置也是有版本的,并且按 REST 资源的方式来管理。
将来的工作
随着时间推移,Kubernetes 会引入粒度更细的 API 版本。
到那时,这里的规则会根据需要进行调整。
弃用一个标志或 CLI 命令
Kubernetes 系统中包含若干不同的、相互协作的程序。
有时,Kubernetes 可能会删除这些程序的某些标志或 CLI 命令(统称“命令行元素”)。
这些程序可以天然地划分到两个大组中:面向用户的和面向管理员的程序。
二者之间的弃用策略略有不同。
除非某个标志显示地通过前缀或文档来标明其为“alpha”或“beta”,
该标志要被视作正式发布的(GA)。
命令行元素相当于系统的 API 的一部分,不过因为它们并没有采用 REST API
一样的方式来管理版本,其弃用规则规定如下:
规则 #5a:面向用户的命令行元素(例如,kubectl)必须在其宣布被弃用其
在以下时长内仍能使用:
GA:12 个月或者 2 个发布版本(取其较长者)
Beta:3 个月或者 1 个发布版本(取其较长者)
Alpha:0 发布版本
规则 #5b:面向管理员的命令行元素(例如,kubelet)必须在其被宣布弃用
之后以下时长内保持可用:
GA:6 个月或 1 个发行版本(取其较长者)
Beta: 3 个月或 1 个发行版本(取其较长者)
Alpha: 0 个发布版本
规则 #6:被弃用的 CLI 元素在被用到时必须能够产生警告,而警告的
产生是可以被禁止的。
弃用某功能特性或行为
在一些较偶然的情形下,某 Kubernetes 发行版本需要弃用系统的某项功能
特性或者行为,而对应的功能特性或行为并不受 API 或 CLI 控制。在这种情况下,
其弃用规则如下:
规则 #7:被弃用的行为必须在被宣布弃用之后至少 1 年时间内必须保持能用。
这并不意味着对系统的所有更改都受此策略约束。
此规则仅适用于重大的、用户可见的行为;这些行为会影响到在 Kubernetes
中运行的应用的正确性,或者影响到 Kubernetes 集群的管理。
此规则也适用于那些被整个移除的功能特性或行为。
上述规则的一个例外是 特性门控(Feature Gates) 。特性门控是一些键值偶对,
允许用户启用或禁用一些试验性的功能特性。
特性门控意在覆盖功能特性的整个开发周期,它们无意成为长期的 API。
因此,它们会在某功能特性正式发布或被抛弃之后被弃用和删除。
随着一个功能特性经过不同的成熟阶段,相关的特性门控也会演化。
与功能特性生命周期对应的特性门控状态为:
Alpha:特性门控默认被禁用,只能由用户显式启用。
Beta:特性门控默认被弃用,可被用户显式禁用。
GA: 特性门控被弃用(参见弃用 ),并且不再起作用。
GA,弃用窗口期结束:特性门控被删除,不再接受调用。
弃用
功能特性在正式发布之前的生命周期内任何时间点都可被移除。
当未正式发布的功能特性被移除时,它们对应的特性门控也被弃用。
当尝试禁用一个不再起作用的特性门控时,该调用会失败,这样可以避免
毫无迹象地执行一些不受支持的场景。
在某些场合,移除一个即将正式发布的功能特性需要很长时间。特性门控
可以保持其功能,直到对应的功能特性被彻底去除,直到那时特性门控
自身才可被弃用。
由于移除一个已经正式发布的功能特性对应的特性门控也需要一定时间,对特性
门控的调用可能一直被允许,前提是特性门控对功能本身无影响且特性门控不会
引发任何错误。
意在允许用户禁用的功能特性应该包含一个在相关联的特性门控中禁用该功能的机制。
特性门控的版本管理与之前讨论的组件版本管理不同,因此其对应的弃用策略如下:
规则 #8:特性门控所对应的功能特性经历下面所列的成熟性阶段转换时,特性门控
必须被弃用。特性门控弃用时必须在以下时长内保持其功能可用:
Beta 特性转为 GA:6 个月或者 2 个发布版本(取其较长者)
Beta 特性转为丢弃:3 个月或者 1 个发布版本(取其较长者)
Alpha 特性转为丢弃:0 个发布版本
规则 #9:已弃用的特色门控再被使用时必须给出警告回应。当特性门控被
弃用时,必须在发布说明和对应的 CLI 帮助信息中通过文档宣布。
警告信息和文档都要标明是否某特性门控不再起作用。
弃用度量值
Kubernetes 控制平面的每个组件都公开度量值(通常是 /metrics
端点),它们通常由集群管理员使用。
并不是所有的度量值都是同样重要的:一些度量值通常用作 SLIs 或被使用来确定 SLOs,这些往往比较重要。
其他度量值在本质上带有实验性,或者主要用于 Kubernetes 开发过程。
因此,度量值分为两个稳定性类别(ALPHA
和 STABLE
);
此分类会影响在 Kubernetes 发布版本中移除某度量值。
所对应的分类取决于对该度量值重要性的预期。
弃用和移除度量值的规则如下:
规则 #9a: 对于相应的稳定性类别,度量值起作用的周期必须不小于:
STABLE: 4 个发布版本或者 12 个月 (取其较长者)
ALPHA: 0 个发布版本
规则 #9b: 在度量值被宣布启用之后,它起作用的周期必须不小于:
STABLE: 3 个发布版本或者 9 个月 (取其较长者)
ALPHA: 0 个发布版本
已弃用的度量值将在其描述文本前加上一个已弃用通知字符串 '(Deprecated from x.y)',
并将在度量值被记录期间发出警告日志。就像稳定的、未被弃用的度量指标一样,
被弃用的度量值将自动注册到 metrics 端点,因此被弃用的度量值也是可见的。
在随后的版本中(当度量值 deprecatedVersion
等于_当前 Kubernetes 版本 - 3_),
被弃用的度量值将变成 _隐藏(Hidden)_ metric 度量值。
与被弃用的度量值不同,隐藏的度量值将不再被自动注册到 metrics 端点(因此被隐藏)。
但是,它们可以通过可执行文件的命令行标志显式启用
(--show-hidden-metrics-for-version=
)。
如果集群管理员不能对早期的弃用警告作出反应,这一设计就为他们提供了抓紧迁移弃用度量值的途径。
隐藏的度量值应该在再过一个发行版本后被删除。
例外
没有策略可以覆盖所有情况。此策略文档是一个随时被更新的文档,会随着时间
推移演化。在实践中,会有一些情况无法很好地匹配到这里的弃用策略,或者
这里的策略变成了很严重的羁绊。这类情形要与 SIG 和项目牵头人讨论,
寻求对应场景的最佳解决方案。请一直铭记,Kubernetes 承诺要成为一个
稳定的系统,至少会尽力做到不会影响到其用户。此弃用策略的任何例外情况
都会在所有相关的发布说明中公布。
2.5 - 已弃用 API 的迁移指南
随着 Kubernetes API 的演化,APIs 会周期性地被重组或升级。
当 APIs 演化时,老的 API 会被弃用并被最终删除。
本页面包含你在将已弃用 API 版本迁移到新的更稳定的 API 版本时需要了解的知识。
各发行版本中移除的 API
v1.26
v1.26 发行版本中将去除以下已弃用的 API 版本:
流控制资源
flowcontrol.apiserver.k8s.io/v1beta1 API 版本的 FlowSchema
和 PriorityLevelConfiguration 将不会在 v1.26 中提供。
迁移清单和 API 客户端使用 flowcontrol.apiserver.k8s.io/v1beta2 API 版本,
此 API 从 v1.23 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
没有需要额外注意的变更
HorizontalPodAutoscaler
autoscaling/v2beta2 API 版本的 HorizontalPodAutoscaler 将不会在
v1.26 版本中提供。
迁移清单和 API 客户端使用 autoscaling/v2 API 版本,
此 API 从 v1.23 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
v1.25
v1.25 发行版本将停止提供以下已废弃 API 版本:
CronJob
batch/v1beta1 API 版本的 CronJob 将不会在 v1.25 版本中继续提供。
迁移清单和 API 客户端使用 batch/v1 API 版本,此 API 从 v1.21 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
没有需要额外注意的变更
EndpointSlice
discovery.k8s.io/v1beta1 API 版本的 EndpointSlice 将不会在 v1.25 版本中继续提供。
迁移清单和 API 客户端使用 discovery.k8s.io/v1 API 版本,此 API 从 v1.21 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
discovery.k8s.io/v1 中值得注意的变更有:
使用每个 Endpoint 的 nodeName
字段而不是已被弃用的
topology["kubernetes.io/hostname"]
字段;
使用每个 Endpoint 的 zone
字段而不是已被弃用的
topology["kubernetes.io/zone"]
字段;
topology
字段被替换为 deprecatedTopology
,并且在 v1 版本中不可写入。
Event
events.k8s.io/v1beta1 API 版本的 Event 将不会在 v1.25 版本中继续提供。
迁移清单和 API 客户端使用 events.k8s.io/v1 API 版本,此 API 从 v1.19 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
events.k8s.io/v1 中值得注意的变更有:
type
字段只能设置为 Normal
和 Warning
之一;
involvedObject
字段被更名为 regarding
;
action
、reason
、reportingController
和 reportingInstance
字段
在创建新的 events.k8s.io/v1 版本 Event 时都是必需的字段;
使用 eventTime
而不是已被弃用的 firstTimestamp
字段
(该字段已被更名为 deprecatedFirstTimestamp
,且不允许出现在新的 events.k8s.io/v1 Event 对象中);
使用 series.lastObservedTime
而不是已被弃用的 lastTimestamp
字段
(该字段已被更名为 deprecatedLastTimestamp
,且不允许出现在新的 events.k8s.io/v1 Event 对象中);
使用 series.count
而不是已被弃用的 count
字段
(该字段已被更名为 deprecatedCount
,且不允许出现在新的 events.k8s.io/v1 Event 对象中);
使用 reportingController
而不是已被弃用的 source.component
字段
(该字段已被更名为 deprecatedSource.component
,且不允许出现在新的 events.k8s.io/v1 Event 对象中);
使用 reportingInstance
而不是已被弃用的 source.host
字段
(该字段已被更名为 deprecatedSource.host
,且不允许出现在新的 events.k8s.io/v1 Event 对象中)。
HorizontalPodAutoscaler
autoscaling/v2beta1 API 版本的 HorizontalPodAutoscaler 将不会在 v1.25 版本中继续提供。
迁移清单和 API 客户端使用 autoscaling/v2 API 版本,此 API 从 v1.23 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
PodDisruptionBudget
policy/v1beta1 API 版本的 PodDisruptionBudget 将不会在 v1.25 版本中继续提供。
迁移清单和 API 客户端使用 policy/v1 API 版本,此 API 从 v1.21 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
policy/v1 中需要额外注意的变更有:
在 policy/v1
版本的 PodDisruptionBudget 中将 spec.selector
设置为空({}
)时会选择名字空间中的所有 Pods(在 policy/v1beta1
版本中,空的 spec.selector
不会选择任何 Pods)。如果 spec.selector
未设置,则在两个 API 版本下都不会选择任何 Pods。
PodSecurityPolicy
policy/v1beta1 API 版本中的 PodSecurityPolicy 将不会在 v1.25 中提供,
并且 PodSecurityPolicy 准入控制器也会被删除。
PodSecurityPolicy 的替换方案仍在讨论过程中,不过当前的用法可以迁移到
第三方准入性质的 Webhook 。
RuntimeClass
node.k8s.io/v1beta1 API 版本中的 RuntimeClass 将不会在 v1.25 中提供。
迁移清单和 API 客户端使用 node.k8s.io/v1 API 版本,此 API 从 v1.20 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
没有需要额外注意的变更
v1.22
v1.22 发行版本停止提供以下已废弃 API 版本:
Webhook 资源
admissionregistration.k8s.io/v1beta1 API 版本的 MutatingWebhookConfiguration
和 ValidatingWebhookConfiguration 不在 v1.22 版本中继续提供。
迁移清单和 API 客户端使用 admissionregistration.k8s.io/v1 API 版本,
此 API 从 v1.16 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
值得注意的变更:
webhooks[*].failurePolicy
在 v1 版本中默认值从 Ignore
改为 Fail
webhooks[*].matchPolicy
在 v1 版本中默认值从 Exact
改为 Equivalent
webhooks[*].timeoutSeconds
在 v1 版本中默认值从 30s
改为 10s
webhooks[*].sideEffects
的默认值被删除,并且该字段变为必须指定;
在 v1 版本中可选的值只能是 None
和 NoneOnDryRun
之一
webhooks[*].admissionReviewVersions
的默认值被删除,在 v1
版本中此字段变为必须指定(AdmissionReview 的被支持版本包括 v1
和 v1beta1
)
webhooks[*].name
必须在通过 admissionregistration.k8s.io/v1
创建的对象列表中唯一
CustomResourceDefinition
apiextensions.k8s.io/v1beta1 API 版本的 CustomResourceDefinition
不在 v1.22 版本中继续提供。
迁移清单和 API 客户端使用 apiextensions/v1 API 版本,此 API 从 v1.16 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
值得注意的变更:
spec.scope
的默认值不再是 Namespaced
,该字段必须显式指定
spec.version
在 v1 版本中被删除;应改用 spec.versions
spec.validation
在 v1 版本中被删除;应改用 spec.versions[*].schema
spec.subresources
在 v1 版本中被删除;应改用 spec.versions[*].subresources
spec.additionalPrinterColumns
在 v1 版本中被删除;应改用
spec.versions[*].additionalPrinterColumns
spec.conversion.webhookClientConfig
在 v1 版本中被移动到
spec.conversion.webhook.clientConfig
中
spec.conversion.conversionReviewVersions
在 v1 版本中被移动到
spec.conversion.webhook.conversionReviewVersions
spec.versions[*].schema.openAPIV3Schema
在创建 v1 版本的
CustomResourceDefinition 对象时变成必需字段,并且其取值必须是一个
结构化的 Schema
spec.preserveUnknownFields: true
在创建 v1 版本的 CustomResourceDefinition
对象时不允许指定;该配置必须在 Schema 定义中使用
x-kubernetes-preserve-unknown-fields: true
来设置
在 v1 版本中,additionalPrinterColumns
的条目中的 JSONPath
字段被更名为
jsonPath
(补丁 #66531 )
APIService
apiregistration/v1beta1 API 版本的 APIService 不在 v1.22 版本中继续提供。
迁移清单和 API 客户端使用 apiregistration.k8s.io/v1 API 版本,此 API 从
v1.10 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
没有需要额外注意的变更
TokenReview
authentication.k8s.io/v1beta1 API 版本的 TokenReview 不在 v1.22 版本中继续提供。
迁移清单和 API 客户端使用 authentication.k8s.io/v1 API 版本,此 API 从
v1.6 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
没有需要额外注意的变更
SubjectAccessReview resources
authorization.k8s.io/v1beta1 API 版本的 LocalSubjectAccessReview、
SelfSubjectAccessReview、SubjectAccessReview 不在 v1.22 版本中继续提供。
迁移清单和 API 客户端使用 authorization.k8s.io/v1 API 版本,此 API 从
v1.6 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
需要额外注意的变更:
spec.group
在 v1 版本中被更名为 spec.groups
(补丁 #32709 )
CertificateSigningRequest
certificates.k8s.io/v1beta1 API 版本的 CertificateSigningRequest 不在
v1.22 版本中继续提供。
迁移清单和 API 客户端使用 certificates.k8s.io/v1 API 版本,此 API 从
v1.19 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
certificates.k8s.io/v1
中需要额外注意的变更:
对于请求证书的 API 客户端而言:
spec.signerName
现在变成必需字段(参阅
已知的 Kubernetes 签署者 ),
并且通过 certificates.k8s.io/v1
API 不可以创建签署者为
kubernetes.io/legacy-unknown
的请求
spec.usages
现在变成必需字段,其中不可以包含重复的字符串值,
并且只能包含已知的用法字符串
对于要批准或者签署证书的 API 客户端而言:
status.conditions
中不可以包含重复的类型
status.conditions[*].status
字段现在变为必需字段
status.certificate
必须是 PEM 编码的,而且其中只能包含 CERTIFICATE
数据块
Lease
coordination.k8s.io/v1beta1 API 版本的 Lease 不在 v1.22 版本中继续提供。
迁移清单和 API 客户端使用 coordination.k8s.io/v1 API 版本,此 API 从
v1.14 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
没有需要额外注意的变更
Ingress
extensions/v1beta1 和 networking.k8s.io/v1beta1 API 版本的 Ingress
不在 v1.22 版本中继续提供。
迁移清单和 API 客户端使用 networking.k8s.io/v1 API 版本,此 API 从
v1.19 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
值得注意的变更:
spec.backend
字段被更名为 spec.defaultBackend
后端的 serviceName
字段被更名为 service.name
数值表示的后端 servicePort
字段被更名为 service.port.number
字符串表示的后端 servicePort
字段被更名为 service.port.name
对所有要指定的路径,pathType
都成为必需字段。
可选项为 Prefix
、Exact
和 ImplementationSpecific
。
要匹配 v1beta1
版本中未定义路径类型时的行为,可使用 ImplementationSpecific
IngressClass
networking.k8s.io/v1beta1 API 版本的 IngressClass 不在 v1.22 版本中继续提供。
迁移清单和 API 客户端使用 networking.k8s.io/v1 API 版本,此 API 从
v1.19 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
没有需要额外注意的变更
RBAC 资源
rbac.authorization.k8s.io/v1beta1 API 版本的 ClusterRole、ClusterRoleBinding、
Role 和 RoleBinding 不在 v1.22 版本中继续提供。
迁移清单和 API 客户端使用 rbac.authorization.k8s.io/v1 API 版本,此 API 从
v1.8 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
没有需要额外注意的变更
PriorityClass
scheduling.k8s.io/v1beta1 API 版本的 PriorityClass 不在 v1.22 版本中继续提供。
迁移清单和 API 客户端使用 scheduling.k8s.io/v1 API 版本,此 API 从
v1.14 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
没有需要额外注意的变更
存储资源
storage.k8s.io/v1beta1 API 版本的 CSIDriver、CSINode、StorageClass
和 VolumeAttachment 不在 v1.22 版本中继续提供。
迁移清单和 API 客户端使用 storage.k8s.io/v1 API 版本
CSIDriver 从 v1.19 版本开始在 storage.k8s.io/v1 中提供;
CSINode 从 v1.17 版本开始在 storage.k8s.io/v1 中提供;
StorageClass 从 v1.6 版本开始在 storage.k8s.io/v1 中提供;
VolumeAttachment 从 v1.13 版本开始在 storage.k8s.io/v1 中提供;
所有的已保存的对象都可以通过新的 API 来访问;
没有需要额外注意的变更
v1.16
v1.16 发行版本停止提供以下已废弃 API 版本:
NetworkPolicy
extensions/v1beta1 API 版本的 NetworkPolicy 不在 v1.16 版本中继续提供。
迁移清单和 API 客户端使用 networking.k8s.io/v1 API 版本,此 API 从
v1.8 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
DaemonSet
extensions/v1beta1 和 apps/v1beta2 API 版本的 DaemonSet 在
v1.16 版本中不再继续提供。
迁移清单和 API 客户端使用 apps/v1 API 版本,此 API 从 v1.9 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
值得注意的变更:
spec.templateGeneration
字段被删除
spec.selector
现在变成必需字段,并且在对象创建之后不可变更;
可以将现有模板的标签作为选择算符以实现无缝迁移。
spec.updateStrategy.type
的默认值变为 RollingUpdate
(extensions/v1beta1
API 版本中的默认值是 OnDelete
)。
Deployment
extensions/v1beta1 、apps/v1beta1 和 apps/v1beta2 API 版本的
Deployment 在 v1.16 版本中不再继续提供。
迁移清单和 API 客户端使用 apps/v1 API 版本,此 API 从 v1.9 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
值得注意的变更:
spec.rollbackTo
字段被删除
spec.selector
字段现在变为必需字段,并且在 Deployment 创建之后不可变更;
可以使用现有的模板的标签作为选择算符以实现无缝迁移。
spec.progressDeadlineSeconds
的默认值变为 600
秒
(extensions/v1beta1
中的默认值是没有期限)
spec.revisionHistoryLimit
的默认值变为 10
(apps/v1beta1
API 版本中此字段默认值为 2
,在extensions/v1beta1
API
版本中的默认行为是保留所有历史记录)。
maxSurge
和 maxUnavailable
的默认值变为 25%
(在 extensions/v1beta1
API 版本中,这些字段的默认值是 1
)。
StatefulSet
apps/v1beta1 和 apps/v1beta2 API 版本的 StatefulSet 在 v1.16 版本中不再继续提供。
迁移清单和 API 客户端使用 apps/v1 API 版本,此 API 从 v1.9 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
值得注意的变更:
spec.selector
字段现在变为必需字段,并且在 StatefulSet 创建之后不可变更;
可以使用现有的模板的标签作为选择算符以实现无缝迁移。
spec.updateStrategy.type
的默认值变为 RollingUpdate
(apps/v1beta1
API 版本中的默认值是 OnDelete
)。
ReplicaSet
extensions/v1beta1 、apps/v1beta1 和 apps/v1beta2 API 版本的
ReplicaSet 在 v1.16 版本中不再继续提供。
迁移清单和 API 客户端使用 apps/v1 API 版本,此 API 从 v1.9 版本开始可用;
所有的已保存的对象都可以通过新的 API 来访问;
值得注意的变更:
spec.selector
现在变成必需字段,并且在对象创建之后不可变更;
可以将现有模板的标签作为选择算符以实现无缝迁移。
PodSecurityPolicy
extensions/v1beta1 API 版本的 PodSecurityPolicy 在 v1.16 版本中不再继续提供。
迁移清单和 API 客户端使用 policy/v1beta1 API 版本,此 API 从 v1.10 版本开始可用;
注意 policy/v1beta1 API 版本的 PodSecurityPolicy 会在 v1.25 版本中移除。
需要做什么
在禁用已启用 API 的情况下执行测试
你可以通过在启动 API 服务器时禁用特定的 API 版本来模拟即将发生的
API 移除,从而完成测试。在 API 服务器启动参数中添加如下标志:
--runtime-config=<group>/<version>=false
例如:
--runtime-config=admissionregistration.k8s.io/v1beta1=false,apiextensions.k8s.io/v1beta1,...
定位何处使用了已弃用的 API
使用 client warnings, metrics, and audit information available in 1.19+
来定位在何处使用了已启用的 API。
迁移到未被弃用的 API
更新自定义的集成组件和控制器,调用未被弃用的 API
更改 YAML 文件引用未被弃用的 API
你可以用 kubectl-convert
命令(在 v1.20 之前是 kubectl convert
)
来自动转换现有对象:
kubectl-convert -f <file> --output-version <group>/<version>
.
例如,要将较老的 Deployment 转换为 apps/v1
版本,你可以运行
kubectl-convert -f ./my-deployment.yaml --output-version apps/v1
注意这种操作生成的结果中可能使用的默认值并不理想。
要进一步了解某个特定资源,可查阅 Kubernetes API 参考 。
2.6 - Kubernetes API 健康端点
Kubernetes API 服务器 提供 API 端点以指示 API 服务器的当前状态。
本文描述了这些 API 端点,并说明如何使用。
API 健康端点
Kubernetes API 服务器提供 3 个 API 端点(healthz
、livez
和 readyz
)来表明 API 服务器的当前状态。
healthz
端点已被弃用(自 Kubernetes v1.16 起),你应该使用更为明确的 livez
和 readyz
端点。
livez
端点可与 --livez-grace-period
标志 一起使用,来指定启动持续时间。
为了正常关机,你可以使用 /readyz
端点并指定 --shutdown-delay-duration
标志 。
检查 API 服务器的 healthz
/livez
/readyz
端点的机器应依赖于 HTTP 状态代码。
状态码 200
表示 API 服务器是 healthy
、live
还是 ready
,具体取决于所调用的端点。
以下更详细的选项供操作人员使用,用来调试其集群或了解 API 服务器的状态。
以下示例将显示如何与运行状况 API 端点进行交互。
对于所有端点,都可以使用 verbose
参数来打印检查项以及检查状态。
这对于操作人员调试 API 服务器的当前状态很有用,这些不打算给机器使用:
curl -k https://localhost:6443/livez?verbose
或从具有身份验证的远程主机:
kubectl get --raw= '/readyz?verbose'
输出将如下所示:
[+]ping ok
[+]log ok
[+]etcd ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
healthz check passed
Kubernetes API 服务器也支持排除特定的检查项。
查询参数也可以像以下示例一样进行组合:
curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
输出显示排除了 etcd
检查:
[+]ping ok
[+]log ok
[+]etcd excluded: ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
[+]shutdown ok
healthz check passed
独立健康检查
FEATURE STATE: Kubernetes v1.23 [alpha]
每个单独的健康检查都会公开一个 HTTP 端点,并且可以单独检查。
单个运行状况检查的模式为 /livez/<healthcheck-name>
,其中 livez
和 readyz
表明你要检查的是 API 服务器是否存活或就绪。
<healthcheck-name>
的路径可以通过上面的 verbose
参数发现 ,并采用 [+]
和 ok
之间的路径。
这些单独的健康检查不应由机器使用,但对于操作人员调试系统而言,是有帮助的:
curl -k https://localhost:6443/livez/etcd
3 - API 访问控制
关于 Kubernetes 如何实现和控制 API 访问的介绍性材料,可阅读
控制 Kubernetes API 的访问 。
参考文档:
3.1 - 用户认证
本页提供身份认证有关的概述。
Kubernetes 中的用户
所有 Kubernetes 集群都有两类用户:由 Kubernetes 管理的服务账号和普通用户。
Kubernetes 假定普通用户是由一个与集群无关的服务通过以下方式之一进行管理的:
负责分发私钥的管理员
类似 Keystone 或者 Google Accounts 这类用户数据库
包含用户名和密码列表的文件
有鉴于此,Kubernetes 并不包含用来代表普通用户账号的对象 。
普通用户的信息无法通过 API 调用添加到集群中。
尽管无法通过 API 调用来添加普通用户,Kubernetes 仍然认为能够提供由集群的证书
机构签名的合法证书的用户是通过身份认证的用户。基于这样的配置,Kubernetes
使用证书中的 'subject' 的通用名称(Common Name)字段(例如,"/CN=bob")来
确定用户名。接下来,基于角色访问控制(RBAC)子系统会确定用户是否有权针对
某资源执行特定的操作。进一步的细节可参阅
证书请求
下普通用户主题。
与此不同,服务账号是 Kubernetes API 所管理的用户。它们被绑定到特定的名字空间,
或者由 API 服务器自动创建,或者通过 API 调用创建。服务账号与一组以 Secret 保存
的凭据相关,这些凭据会被挂载到 Pod 中,从而允许集群内的进程访问 Kubernetes
API。
API 请求则或者与某普通用户相关联,或者与某服务账号相关联,亦或者被视作
匿名请求 。这意味着集群内外的每个进程在向 API 服务器发起
请求时都必须通过身份认证,否则会被视作匿名用户。这里的进程可以是在某工作站上
输入 kubectl
命令的操作人员,也可以是节点上的 kubelet
组件,还可以是控制面
的成员。
身份认证策略
Kubernetes 通过身份认证插件利用客户端证书、持有者令牌(Bearer Token)或身份认证代理(Proxy)
来认证 API 请求的身份。HTTP 请求发给 API 服务器时,插件会将以下属性关联到请求本身:
用户名:用来辩识最终用户的字符串。常见的值可以是 kube-admin
或 jane@example.com
。
用户 ID:用来辩识最终用户的字符串,旨在比用户名有更好的一致性和唯一性。
用户组:取值为一组字符串,其中各个字符串用来标明用户是某个命名的用户逻辑集合的成员。
常见的值可能是 system:masters
或者 devops-team
等。
附加字段:一组额外的键-值映射,键是字符串,值是一组字符串;用来保存一些鉴权组件可能
觉得有用的额外信息。
所有(属性)值对于身份认证系统而言都是不透明的,只有被
鉴权组件
解释过之后才有意义。
你可以同时启用多种身份认证方法,并且你通常会至少使用两种方法:
针对服务账号使用服务账号令牌
至少另外一种方法对用户的身份进行认证
当集群中启用了多个身份认证模块时,第一个成功地对请求完成身份认证的模块会
直接做出评估决定。API 服务器并不保证身份认证模块的运行顺序。
对于所有通过身份认证的用户,system:authenticated
组都会被添加到其组列表中。
与其它身份认证协议(LDAP、SAML、Kerberos、X509 的替代模式等等)都可以通过
使用一个身份认证代理 或
身份认证 Webhoook 来实现。
X509 客户证书
通过给 API 服务器传递 --client-ca-file=SOMEFILE
选项,就可以启动客户端证书身份认证。
所引用的文件必须包含一个或者多个证书机构,用来验证向 API 服务器提供的客户端证书。
如果提供了客户端证书并且证书被验证通过,则 subject 中的公共名称(Common Name)就被
作为请求的用户名。
自 Kubernetes 1.4 开始,客户端证书还可以通过证书的 organization 字段标明用户的组成员信息。
要包含用户的多个组成员信息,可以在证书种包含多个 organization 字段。
例如,使用 openssl
命令行工具生成一个证书签名请求:
openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"
此命令将使用用户名 jbeda
生成一个证书签名请求(CSR),且该用户属于 "app" 和
"app2" 两个用户组。
参阅管理证书 了解如何生成客户端证书。
静态令牌文件
当 API 服务器的命令行设置了 --token-auth-file=SOMEFILE
选项时,会从文件中
读取持有者令牌。目前,令牌会长期有效,并且在不重启 API 服务器的情况下
无法更改令牌列表。
令牌文件是一个 CSV 文件,包含至少 3 个列:令牌、用户名和用户的 UID。
其余列被视为可选的组名。
说明: 如果要设置的组名不止一个,则对应的列必须用双引号括起来,例如
token,user,uid,"group1,group2,group3"
在请求中放入持有者令牌
当使用持有者令牌来对某 HTTP 客户端执行身份认证时,API 服务器希望看到
一个名为 Authorization
的 HTTP 头,其值格式为 Bearer <token>
。
持有者令牌必须是一个可以放入 HTTP 头部值字段的字符序列,至多可使用
HTTP 的编码和引用机制。
例如:如果持有者令牌为 31ada4fd-adec-460c-809a-9e56ceb75269
,则其
出现在 HTTP 头部时如下所示:
Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269
启动引导令牌
FEATURE STATE: Kubernetes v1.18 [stable]
为了支持平滑地启动引导新的集群,Kubernetes 包含了一种动态管理的持有者令牌类型,
称作 启动引导令牌(Bootstrap Token) 。
这些令牌以 Secret 的形式保存在 kube-system
名字空间中,可以被动态管理和创建。
控制器管理器包含的 TokenCleaner
控制器能够在启动引导令牌过期时将其删除。
这些令牌的格式为 [a-z0-9]{6}.[a-z0-9]{16}
。第一个部分是令牌的 ID;第二个部分
是令牌的 Secret。你可以用如下所示的方式来在 HTTP 头部设置令牌:
Authorization: Bearer 781292.db7bc3a58fc5f07e
你必须在 API 服务器上设置 --enable-bootstrap-token-auth
标志来启用基于启动
引导令牌的身份认证组件。
你必须通过控制器管理器的 --controllers
标志来启用 TokenCleaner 控制器;
这可以通过类似 --controllers=*,tokencleaner
这种设置来做到。
如果你使用 kubeadm
来启动引导新的集群,该工具会帮你完成这些设置。
身份认证组件的认证结果为 system:bootstrap:<令牌 ID>
,该用户属于
system:bootstrappers
用户组。
这里的用户名和组设置都是有意设计成这样,其目的是阻止用户在启动引导集群之后
继续使用这些令牌。
这里的用户名和组名可以用来(并且已经被 kubeadm
用来)构造合适的鉴权
策略,以完成启动引导新集群的工作。
请参阅启动引导令牌
以了解关于启动引导令牌身份认证组件与控制器的更深入的信息,以及如何使用
kubeadm
来管理这些令牌。
服务账号令牌
服务账号(Service Account)是一种自动被启用的用户认证机制,使用经过签名的
持有者令牌来验证请求。该插件可接受两个可选参数:
--service-account-key-file
一个包含用来为持有者令牌签名的 PEM 编码密钥。
若未指定,则使用 API 服务器的 TLS 私钥。
--service-account-lookup
如果启用,则从 API 删除的令牌会被回收。
服务账号通常由 API 服务器自动创建并通过 ServiceAccount
准入控制器
关联到集群中运行的 Pod 上。
持有者令牌会挂载到 Pod 中可预知的位置,允许集群内进程与 API 服务器通信。
服务账号也可以使用 Pod 规约的 serviceAccountName
字段显式地关联到 Pod 上。
说明: serviceAccountName
通常会被忽略,因为关联关系是自动建立的。
apiVersion : apps/v1
kind : Deployment
metadata :
name : nginx-deployment
namespace : default
spec :
replicas : 3
template :
metadata :
# ...
spec :
serviceAccountName : bob-the-bot
containers :
- name : nginx
image : nginx:1.14.2
在集群外部使用服务账号持有者令牌也是完全合法的,且可用来为长时间运行的、需要与
Kubernetes API 服务器通信的任务创建标识。要手动创建服务账号,可以使用
kubectl create serviceaccount <名称>
命令。此命令会在当前的名字空间中生成一个
服务账号和一个与之关联的 Secret。
kubectl create serviceaccount jenkins
serviceaccount/jenkins created
查验相关联的 Secret:
kubectl get serviceaccounts jenkins -o yaml
apiVersion : v1
kind : ServiceAccount
metadata :
# ...
secrets :
- name : jenkins-token-1yvwg
所创建的 Secret 中会保存 API 服务器的公开的 CA 证书和一个已签名的 JSON Web
令牌(JWT)。
kubectl get secret jenkins-token-1yvwg -o yaml
apiVersion : v1
data :
ca.crt : <Base64 编码的 API 服务器 CA>
namespace : ZGVmYXVsdA==
token : <Base64 编码的持有者令牌>
kind : Secret
metadata :
# ...
type : kubernetes.io/service-account-token
说明: 字段值是按 Base64 编码的,这是因为 Secret 数据总是采用 Base64 编码来存储。
已签名的 JWT 可以用作持有者令牌,并将被认证为所给的服务账号。
关于如何在请求中包含令牌,请参阅前文 。
通常,这些 Secret 数据会被挂载到 Pod 中以便集群内访问 API 服务器时使用,
不过也可以在集群外部使用。
服务账号被身份认证后,所确定的用户名为 system:serviceaccount:<名字空间>:<服务账号>
,
并被分配到用户组 system:serviceaccounts
和 system:serviceaccounts:<名字空间>
。
警告:由于服务账号令牌保存在 Secret 对象中,任何能够读取这些 Secret 的用户
都可以被认证为对应的服务账号。在为用户授予访问服务账号的权限时,以及对 Secret
的读权限时,要格外小心。
OpenID Connect(OIDC)令牌
OpenID Connect 是一种 OAuth2 认证方式,
被某些 OAuth2 提供者支持,例如 Azure 活动目录、Salesforce 和 Google。
协议对 OAuth2 的主要扩充体现在有一个附加字段会和访问令牌一起返回,
这一字段称作 ID Token(ID 令牌) 。
ID 令牌是一种由服务器签名的 JSON Web 令牌(JWT),其中包含一些可预知的字段,
例如用户的邮箱地址,
要识别用户,身份认证组件使用 OAuth2
令牌响应
中的 id_token
(而非 access_token
)作为持有者令牌。
关于如何在请求中设置令牌,可参见前文 。
sequenceDiagram
participant user as 用户
participant idp as 身份提供者
participant kube as Kubectl
participant api as API 服务器
user ->> idp: 1. 登录到 IdP
activate idp
idp -->> user: 2. 提供 access_token, id_token, 和 refresh_token
deactivate idp
activate user
user ->> kube: 3. 调用 Kubectl 并 设置 --token 为 id_token 或者将令牌添加到 .kube/config
deactivate user
activate kube
kube ->> api: 4. Authorization: Bearer...
deactivate kube
activate api
api ->> api: 5. JWT 签名合法么?
api ->> api: 6. JWT 是否已过期?(iat+exp)
api ->> api: 7. 用户被授权了么?
api -->> kube: 8. 已授权:执行 操作并返回结果
deactivate api
activate kube
kube --x user: 9. 返回结果
deactivate kube
登录到你的身份服务(Identity Provider)
你的身份服务将为你提供 access_token
、id_token
和 refresh_token
在使用 kubectl
时,将 id_token
设置为 --token
标志值,或者将其直接添加到
kubeconfig
中
kubectl
将你的 id_token
放到一个称作 Authorization
的头部,发送给 API 服务器
API 服务器将负责通过检查配置中引用的证书来确认 JWT 的签名是合法的
检查确认 id_token
尚未过期
确认用户有权限执行操作
鉴权成功之后,API 服务器向 kubectl
返回响应
kubectl
向用户提供反馈信息
由于用来验证你是谁的所有数据都在 id_token
中,Kubernetes 不需要再去联系身份服务。
在一个所有请求都是无状态请求的模型中,这一工作方式可以使得身份认证的解决方案更容易处理大规模请求。
不过,此访问也有一些挑战:
Kubernetes 没有提供用来触发身份认证过程的 "Web 界面"。
因为不存在用来收集用户凭据的浏览器或用户接口,你必须自己先行完成对身份服务的认证过程。
id_token
令牌不可收回。因其属性类似于证书,其生命期一般很短(只有几分钟),
所以,每隔几分钟就要获得一个新的令牌这件事可能很让人头疼。
如果需要向 Kubernetes 控制面板执行身份认证,你必须使用 kubectl proxy
命令或者一个能够注入 id_token
的反向代理。
配置 API 服务器
要启用此插件,须在 API 服务器上配置以下标志:
参数
描述
示例
必需?
--oidc-issuer-url
允许 API 服务器发现公开的签名密钥的服务的 URL。只接受模式为 https://
的 URL。此值通常设置为服务的发现 URL,不含路径。例如:"https://accounts.google.com" 或 "https://login.salesforce.com"。此 URL 应指向 .well-known/openid-configuration 下一层的路径。
如果发现 URL 是 https://accounts.google.com/.well-known/openid-configuration
,则此值应为 https://accounts.google.com
是
--oidc-client-id
所有令牌都应发放给此客户 ID。
kubernetes
是
--oidc-username-claim
用作用户名的 JWT 申领(JWT Claim)。默认情况下使用 sub
值,即最终用户的一个唯一的标识符。管理员也可以选择其他申领,例如 email
或者 name
,取决于所用的身份服务。不过,除了 email
之外的申领都会被添加令牌发放者的 URL 作为前缀,以免与其他插件产生命名冲突。
sub
否
--oidc-username-prefix
要添加到用户名申领之前的前缀,用来避免与现有用户名发生冲突(例如:system:
用户)。例如,此标志值为 oidc:
时将创建形如 oidc:jane.doe
的用户名。如果此标志未设置,且 --oidc-username-claim
标志值不是 email
,则默认前缀为 <令牌发放者的 URL>#
,其中 <令牌发放者 URL >
的值取自 --oidc-issuer-url
标志的设定。此标志值为 -
时,意味着禁止添加用户名前缀。
oidc:
否
--oidc-groups-claim
用作用户组名的 JWT 申领。如果所指定的申领确实存在,则其值必须是一个字符串数组。
groups
否
--oidc-groups-prefix
添加到组申领的前缀,用来避免与现有用户组名(如:system:
组)发生冲突。例如,此标志值为 oidc:
时,所得到的用户组名形如 oidc:engineering
和 oidc:infra
。
oidc:
否
--oidc-required-claim
取值为一个 key=value 偶对,意为 ID 令牌中必须存在的申领。如果设置了此标志,则 ID 令牌会被检查以确定是否包含取值匹配的申领。此标志可多次重复,以指定多个申领。
claim=value
否
--oidc-ca-file
指向一个 CA 证书的路径,该 CA 负责对你的身份服务的 Web 证书提供签名。默认值为宿主系统的根 CA。
/etc/kubernetes/ssl/kc-ca.pem
否
很重要的一点是,API 服务器并非一个 OAuth2 客户端,相反,它只能被配置为
信任某一个令牌发放者。这使得使用公共服务(如 Google)的用户可以不信任发放给
第三方的凭据。
如果管理员希望使用多个 OAuth 客户端,他们应该研究一下那些支持 azp
(Authorized Party,被授权方)申领的服务。
azp
是一种允许某客户端代替另一客户端发放令牌的机制。
Kubernetes 并未提供 OpenID Connect 的身份服务。
你可以使用现有的公共的 OpenID Connect 身份服务(例如 Google 或者
其他服务 )。
或者,你也可以选择自己运行一个身份服务,例如
CoreOS dex 、
Keycloak 、
CloudFoundry UAA 或者
Tremolo Security 的 OpenUnison 。
要在 Kubernetes 环境中使用某身份服务,该服务必须:
支持 OpenID connect 发现 ;
但事实上并非所有服务都具备此能力
运行 TLS 协议且所使用的加密组件都未过时
拥有由 CA 签名的证书(即使 CA 不是商业 CA 或者是自签名的 CA 也可以)
关于上述第三条需求,即要求具备 CA 签名的证书,有一些额外的注意事项。
如果你部署了自己的身份服务,而不是使用云厂商(如 Google 或 Microsoft)所提供的服务,
你必须对身份服务的 Web 服务器证书进行签名,签名所用证书的 CA
标志要设置为
TRUE
,即使用的是自签名证书。这是因为 GoLang 的 TLS 客户端实现对证书验证
标准方面有非常严格的要求。如果你手头没有现成的 CA 证书,可以使用 CoreOS
团队所开发的这个脚本
来创建一个简单的 CA 和被签了名的证书与密钥对。
或者你也可以使用
这个类似的脚本 ,
生成一个合法期更长、密钥尺寸更大的 SHA256 证书。
特定系统的安装指令:
使用 kubectl
选项一 - OIDC 身份认证组件
第一种方案是使用 kubectl 的 oidc
身份认证组件,该组件将 id_token
设置
为所有请求的持有者令牌,并且在令牌过期时自动刷新。在你登录到你的身份服务之后,
可以使用 kubectl 来添加你的 id_token
、refresh_token
、client_id
和
client_secret
,以配置该插件。
如果服务在其刷新令牌响应中不包含 id_token
,则此插件无法支持该服务。
这时你应该考虑下面的选项二。
kubectl config set-credentials USER_NAME \
--auth-provider= oidc \
--auth-provider-arg= idp-issuer-url=( issuer url ) \
--auth-provider-arg= client-id=( your client id ) \
--auth-provider-arg= client-secret=( your client secret ) \
--auth-provider-arg= refresh-token=( your refresh token ) \
--auth-provider-arg= idp-certificate-authority=( path to your ca certificate ) \
--auth-provider-arg= id-token=( your id_token )
作为示例,在完成对你的身份服务的身份认证之后,运行下面的命令:
kubectl config set-credentials mmosley \
--auth-provider= oidc \
--auth-provider-arg= idp-issuer-url= https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP \
--auth-provider-arg= client-id= kubernetes \
--auth-provider-arg= client-secret= 1db158f6-177d-4d9c-8a8b-d36869918ec5 \
--auth-provider-arg= refresh-token= q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXqHega4GAXlF+ma+vmYpFcHe5eZR+slBFpZKtQA= \
--auth-provider-arg= idp-certificate-authority= /root/ca.pem \
--auth-provider-arg= id-token= eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw
此操作会生成以下配置:
users :
- name : mmosley
user :
auth-provider :
config :
client-id : kubernetes
client-secret : 1db158f6-177d-4d9c-8a8b-d36869918ec5
id-token : eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw
idp-certificate-authority : /root/ca.pem
idp-issuer-url : https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP
refresh-token : q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXq
name : oidc
当你的 id_token
过期时,kubectl
会尝试使用你的 refresh_token
来刷新你的
id_token
,并且在 .kube/config
文件的 client_secret
中存放 refresh_token
和 id_token
的新值。
选项二 - 使用 --token
选项
kubectl
命令允许你使用 --token
选项传递一个令牌。
你可以将 id_token
的内容复制粘贴过来,作为此标志的取值:
kubectl --token= eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL21sYi50cmVtb2xvLmxhbjo4MDQzL2F1dGgvaWRwL29pZGMiLCJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNDc0NTk2NjY5LCJqdGkiOiI2RDUzNXoxUEpFNjJOR3QxaWVyYm9RIiwiaWF0IjoxNDc0NTk2MzY5LCJuYmYiOjE0NzQ1OTYyNDksInN1YiI6Im13aW5kdSIsInVzZXJfcm9sZSI6WyJ1c2VycyIsIm5ldy1uYW1lc3BhY2Utdmlld2VyIl0sImVtYWlsIjoibXdpbmR1QG5vbW9yZWplZGkuY29tIn0.f2As579n9VNoaKzoF-dOQGmXkFKf1FMyNV0-va_B63jn-_n9LGSCca_6IVMP8pO-Zb4KvRqGyTP0r3HkHxYy5c81AnIh8ijarruczl-TK_yF5akjSTHFZD-0gRzlevBDiH8Q79NAr-ky0P4iIXS8lY9Vnjch5MF74Zx0c3alKJHJUnnpjIACByfF2SCaYzbWFMUNat-K1PaUk5-ujMBG7yYnr95xD-63n8CO8teGUAAEMx6zRjzfhnhbzX-ajwZLGwGUBT4WqjMs70-6a7_8gZmLZb2az1cZynkFRj2BaCkVT3A2RrjeEwZEtGXlMqKJ1_I2ulrOVsYx01_yD35-rw get nodes
Webhook 令牌身份认证
Webhook 身份认证是一种用来验证持有者令牌的回调机制。
--authentication-token-webhook-config-file
指向一个配置文件,其中描述
如何访问远程的 Webhook 服务。
--authentication-token-webhook-cache-ttl
用来设定身份认证决定的缓存时间。
默认时长为 2 分钟。
配置文件使用 kubeconfig
文件的格式。文件中,clusters
指代远程服务,users
指代远程 API 服务
Webhook。下面是一个例子:
# Kubernetes API 版本
apiVersion : v1
# API 对象类别
kind : Config
# clusters 指代远程服务
clusters :
- name : name-of-remote-authn-service
cluster :
certificate-authority : /path/to/ca.pem # 用来验证远程服务的 CA
server : https://authn.example.com/authenticate # 要查询的远程服务 URL。生产环境中建议使用 'https'。
# users 指代 API 服务的 Webhook 配置
users :
- name : name-of-api-server
user :
client-certificate : /path/to/cert.pem # Webhook 插件要使用的证书
client-key : /path/to/key.pem # 与证书匹配的密钥
# kubeconfig 文件需要一个上下文(Context),此上下文用于本 API 服务器
current-context : webhook
contexts :
- context :
cluster : name-of-remote-authn-service
user : name-of-api-sever
name : webhook
当客户端尝试在 API 服务器上使用持有者令牌完成身份认证(
如前 所述)时,
身份认证 Webhook 会用 POST 请求发送一个 JSON 序列化的对象到远程服务。
该对象是 authentication.k8s.io/v1beta1
组的 TokenReview
对象,
其中包含持有者令牌。
Kubernetes 不会强制请求提供此 HTTP 头部。
要注意的是,Webhook API 对象和其他 Kubernetes API 对象一样,也要受到同一
版本兼容规则 约束。
实现者要了解对 Beta 阶段对象的兼容性承诺,并检查请求的 apiVersion
字段,
以确保数据结构能够正常反序列化解析。此外,API 服务器必须启用
authentication.k8s.io/v1beta1
API 扩展组
(--runtime-config=authentication.k8s.io/v1beta1=true
)。
POST 请求的 Body 部分将是如下格式:
{
"apiVersion" : "authentication.k8s.io/v1beta1" ,
"kind" : "TokenReview" ,
"spec" : {
"token" : "<持有者令牌>"
}
}
远程服务应该会填充请求的 status
字段,以标明登录操作是否成功。
响应的 Body 中的 spec
字段会被忽略,因此可以省略。
如果持有者令牌验证成功,应该返回如下所示的响应:
{
"apiVersion" : "authentication.k8s.io/v1beta1" ,
"kind" : "TokenReview" ,
"status" : {
"authenticated" : true ,
"user" : {
"username" : "janedoe@example.com" ,
"uid" : "42" ,
"groups" : [
"developers" ,
"qa"
],
"extra" : {
"extrafield1" : [
"extravalue1" ,
"extravalue2"
]
}
}
}
}
而不成功的请求会返回:
{
"apiVersion" : "authentication.k8s.io/v1beta1" ,
"kind" : "TokenReview" ,
"status" : {
"authenticated" : false
}
}
HTTP 状态码可用来提供进一步的错误语境信息。
身份认证代理
API 服务器可以配置成从请求的头部字段值(如 X-Remote-User
)中辩识用户。
这一设计是用来与某身份认证代理一起使用 API 服务器,代理负责设置请求的头部字段值。
--requestheader-username-headers
必需字段,大小写不敏感。用来设置要获得用户身份所要检查的头部字段名称列表(有序)。第一个包含数值的字段会被用来提取用户名。
--requestheader-group-headers
可选字段,在 Kubernetes 1.6 版本以后支持,大小写不敏感。
建议设置为 "X-Remote-Group"。用来指定一组头部字段名称列表,以供检查用户所属的组名称。
所找到的全部头部字段的取值都会被用作用户组名。
--requestheader-extra-headers-prefix
可选字段,在 Kubernetes 1.6 版本以后支持,大小写不敏感。
建议设置为 "X-Remote-Extra-"。用来设置一个头部字段的前缀字符串,API 服务器会基于所给
前缀来查找与用户有关的一些额外信息。这些额外信息通常用于所配置的鉴权插件。
API 服务器会将与所给前缀匹配的头部字段过滤出来,去掉其前缀部分,将剩余部分
转换为小写字符串并在必要时执行百分号解码
后,构造新的附加信息字段键名。原来的头部字段值直接作为附加信息字段的值。
例如,使用下面的配置:
--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-
针对所收到的如下请求:
GET / HTTP / 1.1
X-Remote-User: fido
X-Remote-Group: dogs
X-Remote-Group: dachshunds
X-Remote-Extra-Acme.com%2Fproject: some-project
X-Remote-Extra-Scopes: openid
X-Remote-Extra-Scopes: profile
会生成下面的用户信息:
name : fido
groups :
- dogs
- dachshunds
extra :
acme.com/project :
- some-project
scopes :
- openid
- profile
为了防范头部信息侦听,在请求中的头部字段被检视之前,
身份认证代理需要向 API 服务器提供一份合法的客户端证书,
供后者使用所给的 CA 来执行验证。
警告:不要 在不同的上下文中复用 CA 证书,除非你清楚这样做的风险是什么以及
应如何保护 CA 用法的机制。
--requestheader-client-ca-file
必需字段,给出 PEM 编码的证书包。
在检查请求的头部字段以提取用户名信息之前,必须提供一个合法的客户端证书,
且该证书要能够被所给文件中的机构所验证。
--requestheader-allowed-names
可选字段,用来给出一组公共名称(CN)。
如果此标志被设置,则在检视请求中的头部以提取用户信息之前,必须提供
包含此列表中所给的 CN 名的、合法的客户端证书。
匿名请求
启用匿名请求支持之后,如果请求没有被已配置的其他身份认证方法拒绝,则被视作
匿名请求(Anonymous Requests)。这类请求获得用户名 system:anonymous
和
对应的用户组 system:unauthenticated
。
例如,在一个配置了令牌身份认证且启用了匿名访问的服务器上,如果请求提供了非法的
持有者令牌,则会返回 401 Unauthorized
错误。
如果请求没有提供持有者令牌,则被视为匿名请求。
在 1.5.1-1.5.x 版本中,匿名访问默认情况下是被禁用的,可以通过为 API 服务器设定
--anonymous-auth=true
来启用。
在 1.6 及之后版本中,如果所使用的鉴权模式不是 AlwaysAllow
,则匿名访问默认是被启用的。
从 1.6 版本开始,ABAC 和 RBAC 鉴权模块要求对 system:anonymous
用户或者
system:unauthenticated
用户组执行显式的权限判定,所以之前的为 *
用户或
*
用户组赋予访问权限的策略规则都不再包含匿名用户。
用户伪装
一个用户可以通过伪装(Impersonation)头部字段来以另一个用户的身份执行操作。
使用这一能力,你可以手动重载请求被身份认证所识别出来的用户信息。
例如,管理员可以使用这一功能特性来临时伪装成另一个用户,查看请求是否被拒绝,
从而调试鉴权策略中的问题,
带伪装的请求首先会被身份认证识别为发出请求的用户,之后会切换到使用被伪装的用户
的用户信息。
用户发起 API 调用时 同时 提供自身的凭据和伪装头部字段信息
API 服务器对用户执行身份认证
API 服务器确认通过认证的用户具有伪装特权
请求用户的信息被替换成伪装字段的值
评估请求,鉴权组件针对所伪装的用户信息执行操作
以下 HTTP 头部字段可用来执行伪装请求:
Impersonate-User
:要伪装成的用户名
Impersonate-Group
:要伪装成的用户组名。可以多次指定以设置多个用户组。
可选字段;要求 "Impersonate-User" 必须被设置。
Impersonate-Extra-<附加名称>
:一个动态的头部字段,用来设置与用户相关的附加字段。
此字段可选;要求 "Impersonate-User" 被设置。为了能够以一致的形式保留,
<附加名称>
部分必须是小写字符,如果有任何字符不是
合法的 HTTP 头部标签字符 ,
则必须是 utf8 字符,且转换为百分号编码 。
Impersonate-Uid
:一个唯一标识符,用来表示所伪装的用户。此头部可选。
如果设置,则要求 "Impersonate-User" 也存在。
Kubernetes 对此字符串没有格式要求。
说明: 在 1.11.3 版本之前(以及 1.10.7、1.9.11),<附加名称>
只能包含
合法的 HTTP 标签字符。
说明:
Impersonate-Uid
仅在 1.22.0 及更高版本中可用。
伪装带有用户组的用户时,所使用的伪装头部字段示例:
Impersonate-User: jane.doe@example.com
Impersonate-Group: developers
Impersonate-Group: admins
伪装带有 UID 和附加字段的用户时,所使用的伪装头部字段示例:
Impersonate-User: jane.doe@example.com
Impersonate-Group: developers
Impersonate-Group: admins
Impersonate-Extra-dn: cn=jane,ou=engineers,dc=example,dc=com
Impersonate-Extra-acme.com%2Fproject: some-project
Impersonate-Extra-scopes: view
Impersonate-Extra-scopes: development
在使用 kubectl
时,可以使用 --as
标志来配置 Impersonate-User
头部字段值,
使用 --as-group
标志配置 Impersonate-Group
头部字段值。
Error from server (Forbidden): User "clark" cannot get nodes at the cluster scope. (get nodes mynode)
设置 --as
和 --as-group
标志:
kubectl drain mynode --as= superman --as-group= system:masters
node/mynode cordoned
node/mynode drained
说明:
kubectl
不能对附加字段或 UID 执行伪装。
若要伪装成某个用户、某个组、用户标识符(UID))或者设置附加字段,
执行伪装操作的用户必须具有对所伪装的类别(“user”、“group”、“uid” 等)执行 “impersonate”
动词操作的能力。
对于启用了 RBAC 鉴权插件的集群,下面的 ClusterRole 封装了设置用户和组伪装字段所需的规则:
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRole
metadata :
name : impersonator
rules :
- apiGroups : ["" ]
resources : ["users" , "groups" , "serviceaccounts" ]
verbs : ["impersonate" ]
为了执行伪装,附加字段和所伪装的 UID 都位于 "authorization.k8s.io" apiGroup
中。
附加字段会被作为 userextras
资源的子资源来执行权限评估。
如果要允许用户为附加字段 “scopes” 和 UID 设置伪装头部,该用户需要被授予以下角色:
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRole
metadata :
name : scopes-and-uid-impersonator
rules :
# 可以设置 "Impersonate-Extra-scopes" 和 "Impersonate-Uid" 头部
- apiGroups : ["authentication.k8s.io" ]
resources : ["userextras/scopes" , "uids" ]
verbs : ["impersonate" ]
你也可以通过约束资源可能对应的 resourceNames
限制伪装头部的取值:
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRole
metadata :
name : limited-impersonator
rules :
# 可以伪装成用户 "jane.doe@example.com"
- apiGroups : ["" ]
resources : ["users" ]
verbs : ["impersonate" ]
resourceNames : ["jane.doe@example.com" ]
# 可以伪装成用户组 "developers" 和 "admins"
- apiGroups : ["" ]
resources : ["groups" ]
verbs : ["impersonate" ]
resourceNames : ["developers" ,"admins" ]
# 可以将附加字段 "scopes" 伪装成 "view" 和 "development"
- apiGroups : ["authentication.k8s.io" ]
resources : ["userextras/scopes" ]
verbs : ["impersonate" ]
resourceNames : ["view" , "development" ]
# 可以伪装 UID "06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b"
- apiGroups : ["authentication.k8s.io" ]
resources : ["uids" ]
verbs : ["impersonate" ]
resourceNames : ["06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b" ]
client-go 凭据插件
FEATURE STATE: Kubernetes v1.22 [stable]
k8s.io/client-go
及使用它的工具(如 kubectl
和 kubelet
)可以执行某个外部
命令来获得用户的凭据信息。
这一特性的目的是便于客户端与 k8s.io/client-go
并不支持的身份认证协议(LDAP、
Kerberos、OAuth2、SAML 等)继承。
插件实现特定于协议的逻辑,之后返回不透明的凭据以供使用。
几乎所有的凭据插件使用场景中都需要在服务器端存在一个支持
Webhook 令牌身份认证组件 的模块,
负责解析客户端插件所生成的凭据格式。
示例应用场景
在一个假想的应用场景中,某组织运行这一个外部的服务,能够将特定用户的已签名的
令牌转换成 LDAP 凭据。此服务还能够对
Webhook 令牌身份认证组件 的请求做出响应以
验证所提供的令牌。用户需要在自己的工作站上安装一个凭据插件。
要对 API 服务器认证身份时:
用户发出 kubectl
命令。
凭据插件提示用户输入 LDAP 凭据,并与外部服务交互,获得令牌。
凭据插件将令牌返回该 client-go,后者将其用作持有者令牌提交给 API 服务器。
API 服务器使用Webhook 令牌身份认证组件 向
外部服务发出 TokenReview
请求。
外部服务检查令牌上的签名,返回用户的用户名和用户组信息。
配置
凭据插件通过 kubectl 配置文件
来作为 user 字段的一部分设置。
apiVersion : v1
kind : Config
users :
- name : my-user
user :
exec :
# 要执行的命令。必需。
command : "example-client-go-exec-plugin"
# 解析 ExecCredentials 资源时使用的 API 版本。必需。
#
# 插件返回的 API 版本必需与这里列出的版本匹配。
#
# 要与支持多个版本的工具(如 client.authentication.k8sio/v1alpha1)集成,
# 可以设置一个环境变量或者向工具传递一个参数标明 exec 插件所期望的版本,
# 或者从 KUBERNETES_EXEC_INFO 环境变量的 ExecCredential 对象中读取版本信息。
apiVersion : "client.authentication.k8s.io/v1"
# 执行此插件时要设置的环境变量。可选字段。
env :
- name : "FOO"
value : "bar"
# 执行插件时要传递的参数。可选字段。
args :
- "arg1"
- "arg2"
# 当可执行文件不存在时显示给用户的文本。可选的。
installHint : |
需要 example-client-go-exec-plugin 来在当前集群上执行身份认证。可以通过以下命令安装:
MacOS: brew install example-client-go-exec-plugin
Ubuntu: apt-get install example-client-go-exec-plugin
Fedora: dnf install example-client-go-exec-plugin
...
# 是否使用 KUBERNETES_EXEC_INFO 环境变量的一部分向这个 exec 插件
# 提供集群信息(可能包含非常大的 CA 数据)
provideClusterInfo : true
# Exec 插件与标准输入 I/O 数据流之间的协议。如果协议无法满足,
# 则插件无法运行并会返回错误信息。合法的值包括 "Never" (Exec 插件从不使用标准输入),
# "IfAvailable" (Exec 插件希望在可以的情况下使用标准输入),
# 或者 "Always" (Exec 插件需要使用标准输入才能工作)。必需字段。
interactiveMode : Never
clusters :
- name : my-cluster
cluster :
server : "https://172.17.4.100:6443"
certificate-authority : "/etc/kubernetes/ca.pem"
extensions :
- name : client.authentication.k8s.io/exec # 为每个集群 exec 配置保留的扩展名
extension :
arbitrary : config
this : 在设置 provideClusterInfo 时可通过环境变量 KUBERNETES_EXEC_INFO 指定
you : ["can" , "put" , "anything" , "here" ]
contexts :
- name : my-cluster
context :
cluster : my-cluster
user : my-user
current-context : my-cluster
apiVersion : v1
kind : Config
users :
- name : my-user
user :
exec :
# 要执行的命令。必需。
command : "example-client-go-exec-plugin"
# 解析 ExecCredentials 资源时使用的 API 版本。必需。
#
# 插件返回的 API 版本必需与这里列出的版本匹配。
#
# 要与支持多个版本的工具(如 client.authentication.k8sio/v1alpha1)集成,
# 可以设置一个环境变量或者向工具传递一个参数标明 exec 插件所期望的版本,
# 或者从 KUBERNETES_EXEC_INFO 环境变量的 ExecCredential 对象中读取版本信息。
apiVersion : "client.authentication.k8s.io/v1"
# 执行此插件时要设置的环境变量。可选字段。
env :
- name : "FOO"
value : "bar"
# 执行插件时要传递的参数。可选字段。
args :
- "arg1"
- "arg2"
# 当可执行文件不存在时显示给用户的文本。可选的。
installHint : |
需要 example-client-go-exec-plugin 来在当前集群上执行身份认证。可以通过以下命令安装:
MacOS: brew install example-client-go-exec-plugin
Ubuntu: apt-get install example-client-go-exec-plugin
Fedora: dnf install example-client-go-exec-plugin
...
# 是否使用 KUBERNETES_EXEC_INFO 环境变量的一部分向这个 exec 插件
# 提供集群信息(可能包含非常大的 CA 数据)
provideClusterInfo : true
# Exec 插件与标准输入 I/O 数据流之间的协议。如果协议无法满足,
# 则插件无法运行并会返回错误信息。合法的值包括 "Never" (Exec 插件从不使用标准输入),
# "IfAvailable" (Exec 插件希望在可以的情况下使用标准输入),
# 或者 "Always" (Exec 插件需要使用标准输入才能工作)。可选字段。
# 默认值为 "IfAvailable"。
interactiveMode : Never
clusters :
- name : my-cluster
cluster :
server : "https://172.17.4.100:6443"
certificate-authority : "/etc/kubernetes/ca.pem"
extensions :
- name : client.authentication.k8s.io/exec # 为每个集群 exec 配置保留的扩展名
extension :
arbitrary : config
this : 在设置 provideClusterInfo 时可通过环境变量 KUBERNETES_EXEC_INFO 指定
you : ["can" , "put" , "anything" , "here" ]
contexts :
- name : my-cluster
context :
cluster : my-cluster
user : my-user
current-context : my-cluster
解析相对命令路径时,kubectl 将其视为与配置文件比较而言的相对路径。
如果 KUBECONFIG 被设置为 /home/jane/kubeconfig
,而 exec 命令为
./bin/example-client-go-exec-plugin
,则要执行的可执行文件为
/home/jane/bin/example-client-go-exec-plugin
。
- name : my-user
user :
exec :
# 对 kubeconfig 目录而言的相对路径
command : "./bin/example-client-go-exec-plugin"
apiVersion : "client.authentication.k8s.io/v1"
interactiveMode : Never
所执行的命令会在 stdout
打印 ExecCredential
对象。
k8s.io/client-go
使用 status
中返回的凭据信息向 Kubernetes API 服务器执行身份认证。
所执行的命令会通过环境变量 KUBERNETES_EXEC_INFO
收到一个 ExecCredential
对象作为其输入。
此输入中包含类似于所返回的 ExecCredential
对象的预期 API 版本,
以及是否插件可以使用 stdin
与用户交互这类信息。
在交互式会话(即,某终端)中运行时,stdin
是直接暴露给插件使用的。
插件应该使用来自 KUBERNETES_EXEC_INFO
环境变量的 ExecCredential
输入对象中的 spec.interactive
字段来确定是否提供了 stdin
。
插件的 stdin
需求(即,为了能够让插件成功运行,是否 stdin
是可选的、
必须提供的或者从不会被使用的)是通过
kubeconfig
中的 user.exec.interactiveMode
来声明的(参见下面的表格了解合法值)。
字段 user.exec.interactiveMode
在 client.authentication.k8s.io/v1beta1
中是可选的,在 client.authentication.k8s.io/v1
中是必需的。
interactiveMode 取值
interactiveMode
取值
含义
Never
此 exec 插件从不需要使用标准输入,因此如论是否有标准输入提供给用户输入,该 exec 插件都能运行。
IfAvailable
此 exec 插件希望在标准输入可用的情况下使用标准输入,但在标准输入不存在时也可运行。因此,无论是否存在给用户提供输入的标准输入,此 exec 插件都会运行。如果存在供用户输入的标准输入,则该标准输入会被提供给 exec 插件。
Always
此 exec 插件需要标准输入才能正常运行,因此只有存在供用户输入的标准输入时,此 exec 插件才会运行。如果不存在供用户输入的标准输入,则 exec 插件无法运行,并且 exec 插件的执行者会因此返回错误信息。
与使用持有者令牌凭据,插件在 ExecCredential
的状态中返回一个令牌:
{
"apiVersion" : "client.authentication.k8s.io/v1" ,
"kind" : "ExecCredential" ,
"status" : {
"token" : "my-bearer-token"
}
}
{
"apiVersion" : "client.authentication.k8s.io/v1beta1" ,
"kind" : "ExecCredential" ,
"status" : {
"token" : "my-bearer-token"
}
}
另一种方案是,返回 PEM 编码的客户端证书和密钥,以便执行 TLS 客户端身份认证。
如果插件在后续调用中返回了不同的证书或密钥,k8s.io/client-go
会终止其与服务器的连接,从而强制执行新的 TLS 握手过程。
如果指定了这种方式,则 clientKeyData
和 clientCertificateData
字段都必需存在。
clientCertificateData
字段可能包含一些要发送给服务器的中间证书(Intermediate
Certificates)。
{
"apiVersion" : "client.authentication.k8s.io/v1" ,
"kind" : "ExecCredential" ,
"status" : {
"clientCertificateData" : "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----" ,
"clientKeyData" : "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"
}
}
{
"apiVersion" : "client.authentication.k8s.io/v1beta1" ,
"kind" : "ExecCredential" ,
"status" : {
"clientCertificateData" : "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----" ,
"clientKeyData" : "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"
}
}
作为一种可选方案,响应中还可以包含以
RFC 3339
时间戳格式给出的证书到期时间。
证书到期时间的有无会有如下影响:
如果响应中包含了到期时间,持有者令牌和 TLS 凭据会被缓存,直到到期期限到来、
或者服务器返回 401 HTTP 状态码,或者进程退出。
如果未指定到期时间,则持有者令牌和 TLS 凭据会被缓存,直到服务器返回 401
HTTP 状态码或者进程退出。
{
"apiVersion" : "client.authentication.k8s.io/v1" ,
"kind" : "ExecCredential" ,
"status" : {
"token" : "my-bearer-token" ,
"expirationTimestamp" : "2018-03-05T17:30:20-08:00"
}
}
{
"apiVersion" : "client.authentication.k8s.io/v1beta1" ,
"kind" : "ExecCredential" ,
"status" : {
"token" : "my-bearer-token" ,
"expirationTimestamp" : "2018-03-05T17:30:20-08:00"
}
}
为了让 exec 插件能够获得特定与集群的信息,可以在
kubeconfig
中的 user.exec
设置 provideClusterInfo
。
这一特定于集群的信息就会通过 KUBERNETES_EXEC_INFO
环境变量传递给插件。
此环境变量中的信息可以用来执行特定于集群的凭据获取逻辑。
下面的 ExecCredential
清单描述的是一个示例集群信息。
{
"apiVersion" : "client.authentication.k8s.io/v1" ,
"kind" : "ExecCredential" ,
"spec" : {
"cluster" : {
"server" : "https://172.17.4.100:6443" ,
"certificate-authority-data" : "LS0t..." ,
"config" : {
"arbitrary" : "config" ,
"this" : "可以在设置 provideClusterInfo 时通过 KUBERNETES_EXEC_INFO 环境变量提供" ,
"you" : ["can" , "put" , "anything" , "here" ]
}
},
"interactive" : true
}
}
{
"apiVersion" : "client.authentication.k8s.io/v1beta1" ,
"kind" : "ExecCredential" ,
"spec" : {
"cluster" : {
"server" : "https://172.17.4.100:6443" ,
"certificate-authority-data" : "LS0t..." ,
"config" : {
"arbitrary" : "config" ,
"this" : "可以在设置 provideClusterInfo 时通过 KUBERNETES_EXEC_INFO 环境变量提供" ,
"you" : ["can" , "put" , "anything" , "here" ]
}
},
"interactive" : true
}
}
接下来
3.2 - 使用启动引导令牌(Bootstrap Tokens)认证
FEATURE STATE: Kubernetes v1.18 [stable]
启动引导令牌是一种简单的持有者令牌(Bearer Token),这种令牌是在新建集群
或者在现有集群中添加新节点时使用的。
它被设计成能够支持 kubeadm
,
但是也可以被用在其他的案例中以便用户在不使用 kubeadm
的情况下启动集群。
它也被设计成可以通过 RBAC 策略,结合
Kubelet TLS 启动引导
系统进行工作。
启动引导令牌被定义成一个特定类型的 Secret(bootstrap.kubernetes.io/token
),
并存在于 kube-system
名字空间中。
这些 Secret 会被 API 服务器上的启动引导认证组件(Bootstrap Authenticator)读取。
控制器管理器中的控制器 TokenCleaner 能够删除过期的令牌。
这些令牌也被用来在节点发现的过程中会使用的一个特殊的 ConfigMap 对象。
BootstrapSigner 控制器也会使用这一 ConfigMap。
令牌格式
启动引导令牌使用 abcdef.0123456789abcdef
的形式。
更加规范地说,它们必须符合正则表达式 [a-z0-9]{6}\.[a-z0-9]{16}
。
令牌的第一部分是 “Token ID”,它是一种公开信息,用于引用令牌并确保不会
泄露认证所使用的秘密信息。
第二部分是“令牌秘密(Token Secret)”,它应该被共享给受信的第三方。
启用启动引导令牌
启用启动引导令牌身份认证
启动引导令牌认证组件可以通过 API 服务器上的如下标志启用:
--enable-bootstrap-token-auth
启动引导令牌被启用后,可以作为持有者令牌的凭据,用于 API 服务器请求的身份认证。
Authorization: Bearer 07401b.f395accd246ae52d
令牌认证为用户名 system:bootstrap:<token id>
并且是组 system:bootstrappers
的成员。额外的组信息可以通过令牌的 Secret 来设置。
过期的令牌可以通过启用控制器管理器中的 tokencleaner
控制器来删除。
每个合法的令牌背后对应着 kube-system
名字空间中的某个 Secret 对象。
你可以从
这里
找到完整设计文档。
这是 Secret 看起来的样子。
apiVersion : v1
kind : Secret
metadata :
# name 必须是 "bootstrap-token-<token id>" 格式的
name : bootstrap-token-07401b
namespace : kube-system
# type 必须是 'bootstrap.kubernetes.io/token'
type : bootstrap.kubernetes.io/token
stringData :
# 供人阅读的描述,可选。
description : "The default bootstrap token generated by 'kubeadm init'."
# 令牌 ID 和秘密信息,必需。
token-id : 07401b
token-secret : base64(f395accd246ae52d)
# 可选的过期时间字段
expiration : "2017-03-10T03:22:11Z"
# 允许的用法
usage-bootstrap-authentication : "true"
usage-bootstrap-signing : "true"
# 令牌要认证为的额外组,必须以 "system:bootstrappers:" 开头
auth-extra-groups : system:bootstrappers:worker,system:bootstrappers:ingress
Secret 的类型必须是 bootstrap.kubernetes.io/token
,而且名字必须是 bootstrap-token-<token id>
。
令牌必须存在于 kube-system
名字空间中。
usage-bootstrap-*
成员表明这个 Secret 的用途。启用时,值必须设置为 true
。
usage-bootstrap-authentication
表示令牌可以作为持有者令牌用于 API 服务器的身份认证。
usage-bootstrap-signing
表示令牌可被用于 cluster-info
ConfigMap 的签名,
就像下面描述的那样。
expiration
字段控制令牌的失效期。过期的令牌在用于身份认证时会被拒绝,在用于
ConfigMap 签名时会被忽略。
过期时间值是遵循 RFC3339 进行编码的 UTC 时间。
启用 TokenCleaner 控制器会自动删除过期的令牌。
使用 kubeadm
管理令牌
你可以使用 kubeadm
工具管理运行中集群上的令牌。
参见 kubeadm token 文档
以了解详细信息。
ConfigMap 签名
除了身份认证,令牌还可以用于签名 ConfigMap。
这一用法发生在集群启动过程的早期,在客户端信任 API 服务器之前。
被签名的 ConfigMap 可以被共享令牌完成身份认证。
通过在控制器管理器上启用 bootstrapsigner
控制器可以启用 ConfigMap 签名特性。
--controllers=*,bootstrapsigner
被签名的 ConfigMap 是 kube-public
名字空间中的 cluster-info
。
典型的工作流中,客户端在未经认证和忽略 TLS 报错的状态下读取这个 ConfigMap。
通过检查 ConfigMap 中嵌入的签名校验 ConfigMap 的载荷。
ConfigMap 会是这个样子的:
apiVersion : v1
kind : ConfigMap
metadata :
name : cluster-info
namespace : kube-public
data :
jws-kubeconfig-07401b : eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U
kubeconfig : |
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: <非常长的证书数据>
server: https://10.138.0.2:6443
name: ""
contexts: []
current-context: ""
kind: Config
preferences: {}
users: []
ConfigMap 的 kubeconfig
成员是一个填好了集群信息的配置文件。
这里主要交换的信息是 certificate-authority-data
。在将来可能会有扩展。
签名是一个使用 “detached” 模式生成的 JWS 签名。
为了检验签名,用户应该按照 JWS 规则(base64 编码且丢掉结尾的 =
)对
kubeconfig
的载荷进行编码。完成编码的载荷会被插入到两个句点中间,形成完整的
JWS。你可以使用完整的令牌(比如 07401b.f395accd246ae52d
)作为共享密钥,
通过 HS256
方式 (HMAC-SHA256) 对 JWS 进行校验。
用户 必须 确保使用了 HS256。
警告:
任何拥有了启动引导令牌的主体都可以为该令牌生成一个合法的签名。
当使用 ConfigMap 签名时,非常不建议针对很多客户使用相同的令牌,因为某个被攻击的
客户可能对另一个一来签名来开启 TLS 信任的客户发起中间人攻击。
参考 kubeadm 实现细节
了解更多信息。
3.3 - 证书签名请求
FEATURE STATE: Kubernetes v1.19 [stable]
证书 API 支持
X.509
的自动化配置,
它为 Kubernetes API 的客户端提供一个编程接口,
用于从证书颁发机构(CA)请求并获取 X.509
证书 。
CertificateSigningRequest(CSR)资源用来向指定的签名者申请证书签名,
在最终签名之前,申请可能被批准,也可能被拒绝。
请求签名流程
CertificateSigningRequest 资源类型允许客户使用它申请发放 X.509 证书。
CertificateSigningRequest 对象 在 spec.request
中包含一个 PEM 编码的 PKCS#10 签名请求。
CertificateSigningRequest 使用 spec.signerName
字段标示 签名者 (请求的接收方)。
注意,spec.signerName
在 certificates.k8s.io/v1
之后的 API 版本是必填项。
在 Kubernetes v1.22 和以后的版本,客户可以可选地设置 spec.expirationSeconds
字段来为颁发的证书设定一个特定的有效期。该字段的最小有效值是 600
,也就是 10 分钟。
创建完成的 CertificateSigningRequest,要先通过批准,然后才能签名。
根据所选的签名者,CertificateSigningRequest 可能会被
控制器 自动批准。
否则,就必须人工批准,
人工批准可以使用 REST API(或 go 客户端),也可以执行 kubectl certificate approve
命令。
同样,CertificateSigningRequest 也可能被驳回,
这就相当于通知了指定的签名者,这个证书不能签名。
对于已批准的证书,下一步是签名。
对应的签名控制器首先验证签名条件是否满足,然后才创建证书。
签名控制器然后更新 CertificateSigningRequest,
将新证书保存到现有 CertificateSigningRequest 对象的 status.certificate
字段中。
此时,字段 status.certificate
要么为空,要么包含一个用 PEM 编码的 X.509 证书。
直到签名完成前,CertificateSigningRequest 的字段 status.certificate
都为空。
一旦 status.certificate
字段完成填充,请求既算完成,
客户端现在可以从 CertificateSigningRequest 资源中获取已签名的证书的 PEM 数据。
当然如果不满足签名条件,签名者可以拒签。
为了减少集群中遗留的过时的 CertificateSigningRequest 资源的数量,
一个垃圾收集控制器将会周期性地运行。
此垃圾收集器会清除在一段时间内没有改变过状态的 CertificateSigningRequests:
已批准的请求:1小时后自动删除
已拒绝的请求:1小时后自动删除
已失败的请求:1小时后自动删除
挂起的请求:24小时后自动删除
所有请求:在颁发的证书过期后自动删除
签名者
也可以指定自定义 signerName。
所有签名者都应该提供自己工作方式的信息,
以便客户端可以预期到他们的 CSR 将发生什么。
此类信息包括:
信任分发 :信任(CA 证书包)是如何分发的。
许可的主体 :当一个受限制的主体(subject)发送请求时,相应的限制和应对手段。
许可的 x509 扩展 :包括 IP subjectAltNames、DNS subjectAltNames、
Email subjectAltNames、URI subjectAltNames 等,请求一个受限制的扩展项时的应对手段。
许可的密钥用途/扩展的密钥用途 :当用途和签名者在 CSR 中指定的用途不同时,
相应的限制和应对手段。
过期时间/证书有效期 :过期时间由签名者确定、由管理员配置、还是由 CSR spec.expirationSeconds
字段指定等,
以及签名者决定的过期时间与 CSR spec.expirationSeconds
字段不同时的应对手段。
允许/不允许 CA 位 :当 CSR 包含一个签名者并不允许的 CA 证书的请求时,相应的应对手段。
一般来说,当 CSR 被批准通过,且证书被签名后,status.certificate
字段
将包含一个 PEM 编码的 X.509 证书。
有些签名者在 status.certificate
字段中存储多个证书。
在这种情况下,签名者的说明文档应当指明附加证书的含义。
例如,这是要在 TLS 握手时提供的证书和中继证书。
PKCS#10 签名请求格式并没有一种标准的方法去设置证书的过期时间或者生命期。
因此,证书的过期时间或者生命期必须通过 CSR 对象的 spec.expirationSeconds
字段来设置。
当 spec.expirationSeconds
没有被指定时,内置的签名者默认使用 ClusterSigningDuration
配置选项
(kube-controller-manager 的命令行选项 --cluster-signing-duration
),该选项的默认值设为 1 年。
当 spec.expirationSeconds
被指定时,spec.expirationSeconds
和 ClusterSigningDuration
中的最小值会被使用。
说明:
spec.expirationSeconds
字段是在 Kubernetes v1.22 中加入的。早期的 Kubernetes 版本并不认识该字段。
v1.22 版本之前的 Kubernetes API 服务器会在创建对象的时候忽略该字段。
Kubernetes 签名者
Kubernetes提供了内置的签名者,每个签名者都有一个众所周知的 signerName
:
kubernetes.io/kube-apiserver-client
:签名的证书将被 API 服务器视为客户证书。
kube-controller-manager 不会自动批准它。
信任分发:签名的证书将被 API 服务器视为客户端证书。CA 证书包不通过任何其他方式分发。
许可的主体:没有主体限制,但审核人和签名者可以选择不批准或不签署。
某些主体,比如集群管理员级别的用户或组因部署和安装方式不同而不同,
所以批准和签署之前需要进行额外仔细审查。
用来限制 system:masters
的 CertificateSubjectRestriction 准入插件默认处于启用状态,
但它通常不是集群中唯一的集群管理员主体。
许可的 x509 扩展:允许 subjectAltName 和 key usage 扩展,弃用其他扩展。
许可的密钥用途:必须包含 ["client auth"]
,但不能包含
["digital signature", "key encipherment", "client auth"]
之外的键。
过期时间/证书有效期:对于 kube-controller-manager 实现的签名者,
设置为 --cluster-signing-duration
选项和 CSR 对象的 spec.expirationSeconds
字段(如有设置该字段)中的最小值。
允许/不允许 CA 位:不允许。
kubernetes.io/kube-apiserver-client-kubelet
: 签名的证书将被 kube-apiserver 视为客户证书。
kube-controller-manager 可以自动批准它。
信任分发:签名的证书将被 API 服务器视为客户端证书。CA 证书包不通过任何其他方式分发。
许可的主体:组织名必须是 ["system:nodes"]
,用户名以 "system:node:
" 开头
许可的 x509 扩展:允许 key usage 扩展,禁用 subjectAltName 扩展,并删除其他扩展。
许可的密钥用途:必须是 ["key encipherment", "digital signature", "client auth"]
过期时间/证书有效期:对于 kube-controller-manager 实现的签名者,
设置为 --cluster-signing-duration
选项和 CSR 对象的 spec.expirationSeconds
字段(如有设置该字段)中的最小值。
允许/不允许 CA 位:不允许。
kubernetes.io/kubelet-serving
: 签名服务证书,该服务证书被 API 服务器视为有效的 kubelet 服务证书,
但没有其他保证。kube-controller-manager 不会自动批准它。
信任分发:签名的证书必须被 kube-apiserver 认可,可有效的中止 kubelet 连接。CA 证书包不通过任何其他方式分发。
许可的主体:组织名必须是 ["system:nodes"]
,用户名以 "system:node:
" 开头
许可的 x509 扩展:允许 key usage、DNSName/IPAddress subjectAltName 等扩展,
禁止 EmailAddress、URI subjectAltName 等扩展,并丢弃其他扩展。
至少有一个 DNS 或 IP 的 SubjectAltName 存在。
许可的密钥用途:必须是 ["key encipherment", "digital signature", "server auth"]
过期时间/证书有效期:对于 kube-controller-manager 实现的签名者,
设置为 --cluster-signing-duration
选项和 CSR 对象的 spec.expirationSeconds
字段(如有设置该字段)中的最小值。
允许/不允许 CA 位:不允许。
kubernetes.io/legacy-unknown
: 不保证信任。Kubernetes 的一些第三方发行版可能会使用它签署的客户端证书。
稳定版的 CertificateSigningRequest API(certificates.k8s.io/v1
以及之后的版本)不允许将
signerName
设置为 kubernetes.io/legacy-unknown
。
kube-controller-manager 不会自动批准这类请求。
信任分发:没有。这个签名者在 Kubernetes 集群中没有标准的信任或分发。
许可的主体:全部。
许可的 x509 扩展:允许 subjectAltName 和 key usage 等扩展,并弃用其他扩展。
许可的密钥用途:全部。
过期时间/证书有效期:对于 kube-controller-manager 实现的签名者,
设置为 --cluster-signing-duration
选项和 CSR 对象的 spec.expirationSeconds
字段(如有设置该字段)中的最小值。
允许/不允许 CA 位 - 不允许。
说明:
注意:所有这些故障仅在 kube-controller-manager 日志中报告。
说明:
spec.expirationSeconds
字段是在 Kubernetes v1.22 中加入的。早期的 Kubernetes 版本并不认识该字段。
v1.22 版本之前的 Kubernetes API 服务器会在创建对象的时候忽略该字段。
对于这些签名者,信任的分发发生在带外(out of band)。上述信任之外的任何信任都是完全巧合的。
例如,一些发行版可能会将 kubernetes.io/legacy-unknown
作为 kube-apiserver 的客户端证书,
但这个做法并不标准。
这些用途都没有以任何方式涉及到 ServiceAccount 中的 Secrets .data[ca.crt]
。
此 CA 证书包只保证使用默认的服务(kubernetes.default.svc
)来验证到 API 服务器的连接。
鉴权
授权创建 CertificateSigningRequest 和检索 CertificateSigningRequest:
verbs(动词): create
、get
、list
、watch
,
group(组):certificates.k8s.io
,
resources:certificatesigningrequests
例如:
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRole
metadata :
name : csr-creator
rules :
- apiGroups :
- certificates.k8s.io
resources :
- certificatesigningrequests
verbs :
- create
- get
- list
- watch
授权批准 CertificateSigningRequest:
verbs(动词): get
、list
、watch
,
group(组):certificates.k8s.io
,
resources(资源):certificatesigningrequests
verbs(动词): update
,
group(组):certificates.k8s.io
,
resources(资源):certificatesigningrequests/approval
verbs(动词):approve
,
group(组):certificates.k8s.io
,
resources(资源):signers
,
resourceName:<signerNameDomain>/<signerNamePath>
或 <signerNameDomain>/*
例如:
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRole
metadata :
name : csr-approver
rules :
- apiGroups :
- certificates.k8s.io
resources :
- certificatesigningrequests
verbs :
- get
- list
- watch
- apiGroups :
- certificates.k8s.io
resources :
- certificatesigningrequests/approval
verbs :
- update
- apiGroups :
- certificates.k8s.io
resources :
- signers
resourceNames :
- example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
verbs :
- approve
授权签名 CertificateSigningRequest:
verbs(动词):get
、list
、watch
,
group(组):certificates.k8s.io
,
resources(资源):certificatesigningrequests
verbs(动词):update
,
group(组):certificates.k8s.io
,
resources(资源):certificatesigningrequests/status
verbs(动词):sign
,
group(组):certificates.k8s.io
,
resources(资源):signers
,
resourceName:<signerNameDomain>/<signerNamePath>
或 <signerNameDomain>/*
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRole
metadata :
name : csr-signer
rules :
- apiGroups :
- certificates.k8s.io
resources :
- certificatesigningrequests
verbs :
- get
- list
- watch
- apiGroups :
- certificates.k8s.io
resources :
- certificatesigningrequests/status
verbs :
- update
- apiGroups :
- certificates.k8s.io
resources :
- signers
resourceNames :
- example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
verbs :
- sign
普通用户
为了让普通用户能够通过认证并调用 API,需要执行几个步骤。
首先,该用户必须拥有 Kubernetes 集群签发的证书,
然后将该证书提供给 Kubernetes API。
创建私钥
下面的脚本展示了如何生成 PKI 私钥和 CSR。
设置 CSR 的 CN 和 O 属性很重要。CN 是用户名,O 是该用户归属的组。
你可以参考 RBAC 了解标准组的信息。
openssl genrsa -out myuser.key 2048
openssl req -new -key myuser.key -out myuser.csr
创建 CertificateSigningRequest
创建一个 CertificateSigningRequest,并通过 kubectl 将其提交到 Kubernetes 集群。
下面是生成 CertificateSigningRequest 的脚本。
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: myuser
spec:
request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
signerName: kubernetes.io/kube-apiserver-client
expirationSeconds: 86400 # one day
usages:
- client auth
EOF
需要注意的几点:
usage
字段必须是 'client auth
'
expirationSeconds
可以设置为更长(例如 864000
是十天)或者更短(例如 3600
是一个小时)
request
字段是 CSR 文件内容的 base64 编码值。
要得到该值,可以执行命令 cat myuser.csr | base64 | tr -d "\n"
。
批准证书签名请求
使用 kubectl 创建 CSR 并批准。
获取 CSR 列表:
批准 CSR:
kubectl certificate approve myuser
取得证书
从 CSR 取得证书:
kubectl get csr/myuser -o yaml
证书的内容使用 base64 编码,存放在字段 status.certificate
。
从 CertificateSigningRequest 导出颁发的证书。
kubectl get csr myuser -o jsonpath='{.status.certificate}'| base64 -d > myuser.crt
创建角色和角色绑定
创建了证书之后,为了让这个用户能访问 Kubernetes 集群资源,现在就要创建
Role 和 RoleBinding 了。
下面是为这个新用户创建 Role 的示例命令:
kubectl create role developer --verb= create --verb= get --verb= list --verb= update --verb= delete --resource= pods
下面是为这个新用户创建 RoleBinding 的示例命令:
kubectl create rolebinding developer-binding-myuser --role= developer --user= myuser
添加到 kubeconfig
最后一步是将这个用户添加到 kubeconfig 文件。
我们假设私钥和证书文件存放在 “/home/vagrant/work/” 目录中。
首先,我们需要添加新的凭据:
kubectl config set-credentials myuser --client-key= myuser.key --client-certificate= myuser.crt --embed-certs= true
然后,你需要添加上下文:
kubectl config set-context myuser --cluster= kubernetes --user= myuser
来测试一下,把上下文切换为 myuser
:
kubectl config use-context myuser
批准和驳回
控制平面的自动化批准
kube-controller-manager 内建了一个证书批准者,其 signerName 为
kubernetes.io/kube-apiserver-client-kubelet
,
该批准者将 CSR 上用于节点凭据的各种权限委托给权威认证机构。
kube-controller-manager 将 SubjectAccessReview 资源发送(POST)到 API 服务器,
以便检验批准证书的授权。
使用 kubectl
批准或驳回
Kubernetes 管理员(拥有足够的权限)可以手工批准(或驳回)CertificateSigningRequests,
此操作使用 kubectl certificate approve
和 kubectl certificate deny
命令实现。
使用 kubectl 批准一个 CSR:
kubectl certificate approve <certificate-signing-request-name>
同样地,驳回一个 CSR:
kubectl certificate deny <certificate-signing-request-name>
使用 Kubernetes API 批准或驳回
REST API 的用户可以通过向待批准的 CSR 的 approval
子资源提交更新请求来批准 CSR。
例如,你可以编写一个
operator
来监视特定类型的 CSR,然后发送一个更新来批准它。
当你发出批准或驳回的指令时,根据你期望的状态来选择设置 Approved
或 Denied
。
批准(Approved
) 的 CSR:
apiVersion : certificates.k8s.io/v1
kind : CertificateSigningRequest
...
status :
conditions :
- lastUpdateTime : "2020-02-08T11:37:35Z"
lastTransitionTime : "2020-02-08T11:37:35Z"
message : Approved by my custom approver controller
reason : ApprovedByMyPolicy # You can set this to any string
type : Approved
驳回(Denied
)的 CSR:
apiVersion : certificates.k8s.io/v1
kind : CertificateSigningRequest
...
status :
conditions :
- lastUpdateTime : "2020-02-08T11:37:35Z"
lastTransitionTime : "2020-02-08T11:37:35Z"
message : Denied by my custom approver controller
reason : DeniedByMyPolicy # You can set this to any string
type : Denied
status.conditions.reason
字段通常设置为一个首字母大写的对机器友好的原因码;
这是一个命名约定,但你也可以随你的个人喜好设置。
如果你想添加一个供人类使用的注释,那就用 status.conditions.message
字段。
签名
控制平面签名者
Kubernetes 控制平面实现了每一个
Kubernetes 签名者 ,
每个签名者的实现都是 kube-controller-manager 的一部分。
说明: 在Kubernetes v1.18 之前,
kube-controller-manager 签名所有标记为 approved 的 CSR。
说明:
spec.expirationSeconds
字段是在 Kubernetes v1.22 中加入的。早期的 Kubernetes 版本并不认识该字段。
v1.22 版本之前的 Kubernetes API 服务器会在创建对象的时候忽略该字段。
基于 API 的签名者
REST API 的用户可以通过向待签名的 CSR 的 status
子资源提交更新请求来对 CSR 进行签名。
作为这个请求的一部分, status.certificate
字段应设置为已签名的证书。
此字段可包含一个或多个 PEM 编码的证书。
所有的 PEM 块必须具备 "CERTIFICATE" 标签,且不包含文件头,且编码的数据必须是
RFC5280 第 4 节
中描述的 BER 编码的 ASN.1 证书结构。
-----BEGIN CERTIFICATE-----
MIIDgjCCAmqgAwIBAgIUC1N1EJ4Qnsd322BhDPRwmg3b/oAwDQYJKoZIhvcNAQEL
BQAwXDELMAkGA1UEBhMCeHgxCjAIBgNVBAgMAXgxCjAIBgNVBAcMAXgxCjAIBgNV
BAoMAXgxCjAIBgNVBAsMAXgxCzAJBgNVBAMMAmNhMRAwDgYJKoZIhvcNAQkBFgF4
MB4XDTIwMDcwNjIyMDcwMFoXDTI1MDcwNTIyMDcwMFowNzEVMBMGA1UEChMMc3lz
dGVtOm5vZGVzMR4wHAYDVQQDExVzeXN0ZW06bm9kZToxMjcuMC4wLjEwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDne5X2eQ1JcLZkKvhzCR4Hxl9+ZmU3
+e1zfOywLdoQxrPi+o4hVsUH3q0y52BMa7u1yehHDRSaq9u62cmi5ekgXhXHzGmm
kmW5n0itRECv3SFsSm2DSghRKf0mm6iTYHWDHzUXKdm9lPPWoSOxoR5oqOsm3JEh
Q7Et13wrvTJqBMJo1GTwQuF+HYOku0NF/DLqbZIcpI08yQKyrBgYz2uO51/oNp8a
sTCsV4OUfyHhx2BBLUo4g4SptHFySTBwlpRWBnSjZPOhmN74JcpTLB4J5f4iEeA7
2QytZfADckG4wVkhH3C2EJUmRtFIBVirwDn39GXkSGlnvnMgF3uLZ6zNAgMBAAGj
YTBfMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDAjAMBgNVHRMB
Af8EAjAAMB0GA1UdDgQWBBTREl2hW54lkQBDeVCcd2f2VSlB1DALBgNVHREEBDAC
ggAwDQYJKoZIhvcNAQELBQADggEBABpZjuIKTq8pCaX8dMEGPWtAykgLsTcD2jYr
L0/TCrqmuaaliUa42jQTt2OVsVP/L8ofFunj/KjpQU0bvKJPLMRKtmxbhXuQCQi1
qCRkp8o93mHvEz3mTUN+D1cfQ2fpsBENLnpS0F4G/JyY2Vrh19/X8+mImMEK5eOy
o0BMby7byUj98WmcUvNCiXbC6F45QTmkwEhMqWns0JZQY+/XeDhEcg+lJvz9Eyo2
aGgPsye1o3DpyXnyfJWAWMhOz7cikS5X2adesbgI86PhEHBXPIJ1v13ZdfCExmdd
M1fLPhLyR54fGaY+7/X8P9AZzPefAkwizeXwe9ii6/a08vWoiE4=
-----END CERTIFICATE-----
非 PEM 内容可能会出现在证书 PEM 块前后的位置,且未经验证,
以允许使用 RFC7468 第5.2节 中描述的解释性文本。
当使用 JSON 或 YAML 格式时,此字段是 base-64 编码。
包含上述示例证书的 CertificateSigningRequest 如下所示:
apiVersion : certificates.k8s.io/v1
kind : CertificateSigningRequest
...
status :
certificate : "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JS..."
接下来
3.4 - 使用准入控制器
此页面概述了准入控制器。
什么是准入控制插件?
准入控制器是一段代码,它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API
服务器的请求。控制器由下面的列表 组成,
并编译进 kube-apiserver
二进制文件,并且只能由集群管理员配置。
在该列表中,有两个特殊的控制器:MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。
它们根据 API 中的配置,分别执行变更和验证
准入控制 webhook 。
准入控制器可以执行 “验证(Validating)” 和/或 “变更(Mutating)” 操作。
变更(mutating)控制器可以根据被其接受的请求修改相关对象;验证(validating)控制器则不行。
准入控制器限制创建、删除、修改对象或连接到代理的请求,不限制读取对象的请求。
准入控制过程分为两个阶段。第一阶段,运行变更准入控制器。第二阶段,运行验证准入控制器。
再次提醒,某些控制器既是变更准入控制器又是验证准入控制器。
如果任何一个阶段的任何控制器拒绝了该请求,则整个请求将立即被拒绝,并向终端用户返回一个错误。
最后,除了对对象进行变更外,准入控制器还可以有其它作用:将相关资源作为请求处理的一部分进行变更。
增加使用配额就是一个典型的示例,说明了这样做的必要性。
此类用法都需要相应的回收或回调过程,因为任一准入控制器都无法确定某个请求能否通过所有其它准入控制器。
为什么需要准入控制器?
Kubernetes 的许多高级功能都要求启用一个准入控制器,以便正确地支持该特性。
因此,没有正确配置准入控制器的 Kubernetes API 服务器是不完整的,它无法支持你期望的所有特性。
如何启用一个准入控制器?
Kubernetes API 服务器的 enable-admission-plugins
标志接受一个用于在集群修改对象之前
调用的(以逗号分隔的)准入控制插件顺序列表。
例如,下面的命令就启用了 NamespaceLifecycle
和 LimitRanger
准入控制插件:
kube-apiserver --enable-admission-plugins= NamespaceLifecycle,LimitRanger ...
说明:
根据你 Kubernetes 集群的部署方式以及 API 服务器的启动方式的不同,你可能需要以不同的方式应用设置。
例如,如果将 API 服务器部署为 systemd 服务,你可能需要修改 systemd 单元文件;
如果以自托管方式部署 Kubernetes,你可能需要修改 API 服务器的清单文件。
怎么关闭准入控制器?
Kubernetes API 服务器的 disable-admission-plugins
标志,会将传入的(以逗号分隔的)
准入控制插件列表禁用,即使是默认启用的插件也会被禁用。
kube-apiserver --disable-admission-plugins= PodNodeSelector,AlwaysDeny ...
哪些插件是默认启用的?
下面的命令可以查看哪些插件是默认启用的:
kube-apiserver -h | grep enable-admission-plugins
在目前版本中,它们是:
CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook
每个准入控制器的作用是什么?
AlwaysAdmit
FEATURE STATE: Kubernetes v1.13 [deprecated]
该准入控制器会允许所有的 pod 接入集群。已废弃,因为它的行为根本就和没有准入控制器一样。
AlwaysDeny
FEATURE STATE: Kubernetes v1.13 [deprecated]
拒绝所有的请求。由于它没有实际意义,已废弃。
AlwaysPullImages
该准入控制器会修改每一个新创建的 Pod 的镜像拉取策略为 Always 。
这在多租户集群中是有用的,这样用户就可以放心,他们的私有镜像只能被那些有凭证的人使用。
如果没有这个准入控制器,一旦镜像被拉取到节点上,任何用户的 Pod 都可以通过已了解到的镜像
的名称(假设 Pod 被调度到正确的节点上)来使用它,而不需要对镜像进行任何授权检查。
当启用这个准入控制器时,总是在启动容器之前拉取镜像,这意味着需要有效的凭证。
CertificateApproval
此准入控制器获取“审批” CertificateSigningRequest 资源的请求并执行额外的授权检查,
以确保审批请求的用户有权限审批 spec.signerName
请求 CertificateSigningRequest 资源的证书请求。
有关对证书签名请求资源执行不同操作所需权限的详细信息,
请参阅证书签名请求
CertificateSigning
此准入控制器获取 CertificateSigningRequest 资源的 status.certificate
字段更新请求并执行额外的授权检查,
以确保签发证书的用户有权限为 spec.signerName
请求 CertificateSigningRequest 资源的证书请求签发
证书。
有关对证书签名请求资源执行不同操作所需权限的详细信息,
请参阅证书签名请求
CertificateSubjectRestrictions
此准入控制器获取具有 kubernetes.io/kube-apiserver-client
的 spec.signerName
的
CertificateSigningRequest 资源创建请求,
它拒绝任何包含了 system:masters
一个“组”(或者“组织”)的请求。
DefaultIngressClass
该准入控制器监测没有请求任何特定 Ingress 类的 Ingress
对象的创建,并自动向其添加默认 Ingress 类。
这样,没有任何特殊 Ingress 类需求的用户根本不需要关心它们,它们将获得默认 Ingress 类。
当未配置默认 Ingress 类时,此准入控制器不执行任何操作。如果将多个 Ingress 类标记为默认 Ingress 类,
它将拒绝任何创建 Ingress
的操作,并显示错误。
要修复此错误,管理员必须重新检查其 IngressClass
对象,并仅将其中一个标记为默认(通过注解
"ingressclass.kubernetes.io/is-default-class")。
此准入控制器会忽略所有 Ingress
更新操作,仅响应创建操作。
关于 Ingress 类以及如何将 Ingress 类标记为默认的更多信息,请参见
ingress 。
DefaultStorageClass
该准入控制器监测没有请求任何特定存储类的 PersistentVolumeClaim
对象的创建,
并自动向其添加默认存储类。
这样,没有任何特殊存储类需求的用户根本不需要关心它们,它们将获得默认存储类。
当未配置默认存储类时,此准入控制器不执行任何操作。如果将多个存储类标记为默认存储类,
它将拒绝任何创建 PersistentVolumeClaim
的操作,并显示错误。
要修复此错误,管理员必须重新访问其 StorageClass
对象,并仅将其中一个标记为默认。
此准入控制器会忽略所有 PersistentVolumeClaim
更新操作,仅响应创建操作。
关于持久化卷和存储类,以及如何将存储类标记为默认,请参见
持久化卷 。
DefaultTolerationSeconds
该准入控制器基于 k8s-apiserver 输入参数 default-not-ready-toleration-seconds
和
default-unreachable-toleration-seconds
为 Pod 设置默认的容忍度,以容忍 notready:NoExecute
和
unreachable:NoExecute
污点。
(如果 Pod 尚未容忍 node.kubernetes.io/not-ready:NoExecute
和
node.kubernetes.io/unreachable:NoExecute
污点的话)
default-not-ready-toleration-seconds
和 default-unreachable-toleration-seconds
的默认值是 5 分钟。
DenyEscalatingExec
FEATURE STATE: Kubernetes v1.13 [deprecated]
该准入控制器将拒绝在由于拥有升级特权,而具备访问宿主机能力的 Pod 中执行 exec 和
attach 命令。这包括在特权模式运行的 Pod,可以访问主机 IPC 名字空间的 Pod,
和访问主机 PID 名字空间的 Pod 。
DenyExecOnPrivileged 准入插件已被废弃。
建议使用基于策略的准入插件(例如 PodSecurityPolicy 和自定义准入插件),
该插件可以针对特定用户或名字空间,还可以防止创建权限过高的 Pod。
DenyExecOnPrivileged
FEATURE STATE: Kubernetes v1.13 [deprecated]
如果一个 pod 拥有一个特权容器,该准入控制器将拦截所有在该 pod 中执行 exec 命令的请求。
此功能已合并至 DenyEscalatingExec 。
而 DenyExecOnPrivileged 准入插件已被废弃。
建议使用基于策略的准入插件(例如 PodSecurityPolicy 和自定义准入插件),
该插件可以针对特定用户或名字空间,还可以防止创建权限过高的 Pod。
DenyServiceExternalIPs
该准入控制器拒绝 Service
字段 externalIPs
的所有新规使用。 此功能非常强大(允许网络流量拦截),
并且无法很好地受策略控制。 启用后,群集用户将无法创建使用 externalIPs
的新服务,也无法在现有
Service
对象上向 externalIPs
添加新值。 externalIPs
的现有使用不受影响,用户可以从现有
Service
对象上的 externalIPs
中删除值。
大多数用户根本不需要此功能,集群管理员应考虑将其禁用。
确实需要使用此功能的集群应考虑使用一些自定义策略来管理其的使用。
EventRateLimit
FEATURE STATE: Kubernetes v1.13 [alpha]
该准入控制器缓解了事件请求淹没 API 服务器的问题。集群管理员可以通过以下方式指定事件速率限制:
启用 EventRateLimit
准入控制器;
从文件中引用 EventRateLimit
配置文件,并提供给 API 服务器命令的
--admission-control-config-file
标志:
apiVersion : apiserver.config.k8s.io/v1
kind : AdmissionConfiguration
plugins :
- name : EventRateLimit
path : eventconfig.yaml
...
# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1
apiVersion : apiserver.k8s.io/v1alpha1
kind : AdmissionConfiguration
plugins :
- name : EventRateLimit
path : eventconfig.yaml
...
可以在配置中指定四种类型的限制:
Server
: API 服务器收到的所有事件请求共享一个桶。
Namespace
: 每个名字空间都有一个专用的桶。
User
: 给每个用户都分配一个桶。
SourceAndObject
: 根据事件的源和涉及对象的每种组合分配桶。
下面是一个配置示例 eventconfig.yaml
:
apiVersion : eventratelimit.admission.k8s.io/v1alpha1
kind : Configuration
limits :
- type : Namespace
qps : 50
burst : 100
cacheSize : 2000
- type : User
qps : 10
burst : 50
详情请参见
事件速率限制提案 。
ExtendedResourceToleration
该插件有助于创建可扩展资源的专用节点。
如果运营商想创建可扩展资源的专用节点(如 GPU、FPGA 等),
那他们应该以扩展资源名称作为键名,
为节点设置污点 。
如果启用了该准入控制器,会将此类污点的容忍自动添加到请求扩展资源的 Pod 中,
用户不必再手动添加这些容忍。
ImagePolicyWebhook
ImagePolicyWebhook 准入控制器允许使用一个后端的 webhook 做出准入决策。
配置文件格式
ImagePolicyWebhook 使用配置文件来为后端行为设置配置选项。该文件可以是 JSON 或 YAML,
并具有以下格式:
imagePolicy :
kubeConfigFile : /path/to/kubeconfig/for/backend
# 以秒计的时长,控制批准请求的缓存时间
allowTTL : 50
# 以秒计的时长,控制批准请求的缓存时间
denyTTL : 50
# 以毫秒计的时长,控制重试间隔
retryBackoff : 500
# 确定 Webhook 后端失效时的行为
defaultAllow : true
从文件中引用 ImagePolicyWebhook 的配置文件,并将其提供给 API 服务器命令标志
--admission-control-config-file
:
apiVersion : apiserver.config.k8s.io/v1
kind : AdmissionConfiguration
plugins :
- name : ImagePolicyWebhook
path : imagepolicyconfig.yaml
...
# v1.17 中已废弃以鼓励使用 apiserver.config.k8s.io/v1
apiVersion : apiserver.k8s.io/v1alpha1
kind : AdmissionConfiguration
plugins :
- name : ImagePolicyWebhook
path : imagepolicyconfig.yaml
...
或者,你也可以直接将配置嵌入到文件中:
apiVersion : apiserver.config.k8s.io/v1
kind : AdmissionConfiguration
plugins :
- name : ImagePolicyWebhook
configuration :
imagePolicy :
kubeConfigFile : <kubeconfig 文件路径>
allowTTL : 50
denyTTL : 50
retryBackoff : 500
defaultAllow : true
# v1.17 中已废弃以鼓励使用 apiserver.config.k8s.io/v1
apiVersion : apiserver.k8s.io/v1alpha1
kind : AdmissionConfiguration
plugins :
- name : ImagePolicyWebhook
configuration :
imagePolicy :
kubeConfigFile : <kubeconfig 文件路径>
allowTTL : 50
denyTTL : 50
retryBackoff : 500
defaultAllow : true
ImagePolicyWebhook 的配置文件必须引用
kubeconfig
格式的文件;该文件设置了到后端的连接参数。
要求后端使用 TLS 进行通信。
kubeconfig 文件的 cluster 字段需要指向远端服务,user 字段需要包含已返回的授权者。
# clusters 指的是远程服务。
clusters :
- name : name-of-remote-imagepolicy-service
cluster :
certificate-authority : /path/to/ca.pem # CA 用于验证远程服务
server : https://images.example.com/policy # 要查询的远程服务的 URL。必须是 'https' 。
# users 指的是 API 服务器的 Webhook 配置。
users :
- name : name-of-api-server
user :
client-certificate : /path/to/cert.pem # webhook 准入控制器使用的证书
client-key : /path/to/key.pem # 证书匹配的密钥
关于 HTTP 配置的更多信息,请参阅
kubeconfig
文档。
请求载荷
当面对一个准入决策时,API 服务器发送一个描述操作的 JSON 序列化的
imagepolicy.k8s.io/v1alpha1
ImageReview
对象。
该对象包含描述被审核容器的字段,以及所有匹配 *.image-policy.k8s.io/*
的
Pod 注解。
注意,Webhook API 对象与其他 Kubernetes API 对象一样受制于相同的版本控制兼容性规则。
实现者应该知道对 alpha 对象的更宽松的兼容性,并检查请求的 "apiVersion" 字段,
以确保正确的反序列化。
此外,API 服务器必须启用 imagepolicy.k8s.io/v1alpha1
API 扩展组
(--runtime-config=imagepolicy.k8s.io/v1alpha1=true
)。
请求载荷示例:
{
"apiVersion" :"imagepolicy.k8s.io/v1alpha1" ,
"kind" :"ImageReview" ,
"spec" :{
"containers" :[
{
"image" :"myrepo/myimage:v1"
},
{
"image" :"myrepo/myimage@sha256:beb6bd6a68f114c1dc2ea4b28db81bdf91de202a9014972bec5e4d9171d90ed"
}
],
"annotations" :{
"mycluster.image-policy.k8s.io/ticket-1234" : "break-glass"
},
"namespace" :"mynamespace"
}
}
远程服务将填充请求的 ImageReviewStatus
字段,并返回允许或不允许访问的响应。
响应体的 "spec" 字段会被忽略,并且可以省略。一个允许访问应答会返回:
{
"apiVersion" : "imagepolicy.k8s.io/v1alpha1" ,
"kind" : "ImageReview" ,
"status" : {
"allowed" : true
}
}
若不允许访问,服务将返回:
{
"apiVersion" : "imagepolicy.k8s.io/v1alpha1" ,
"kind" : "ImageReview" ,
"status" : {
"allowed" : false ,
"reason" : "image currently blacklisted"
}
}
更多的文档,请参阅 imagepolicy.v1alpha1
API 对象和
plugin/pkg/admission/imagepolicy/admission.go
。
使用注解进行扩展
一个 Pod 中匹配 *.image-policy.k8s.io/*
的注解都会被发送给 Webhook。
这样做使得了解后端镜像策略的用户可以向它发送额外的信息,并为不同的后端实现
接收不同的信息。
你可以在这里输入的信息有:
在紧急情况下,请求 "break glass" 覆盖一个策略。
从一个记录了 break-glass 的请求的 ticket 系统得到的一个 ticket 号码。
向策略服务器提供一个提示,用于提供镜像的 imageID,以方便它进行查找。
在任何情况下,注解都是由用户提供的,并不会被 Kubernetes 以任何方式进行验证。
在将来,如果一个注解确定将被广泛使用,它可能会被提升为 ImageReviewSpec 的一个命名字段。
LimitPodHardAntiAffinityTopology
该准入控制器拒绝(定义了 AntiAffinity
拓扑键的)任何 Pod
(requiredDuringSchedulingRequiredDuringExecution
中的
kubernetes.io/hostname
除外)。
LimitRanger
该准入控制器会观察传入的请求,并确保它不会违反 Namespace
中 LimitRange
对象枚举的任何约束。
如果你在 Kubernetes 部署中使用了 LimitRange
对象,则必须使用此准入控制器来
执行这些约束。
LimitRanger 还可以用于将默认资源请求应用到没有指定任何内容的 Pod;
当前,默认的 LimitRanger 对 default
名字空间中的所有 Pod 都应用了
0.1 CPU 的需求。
请查看
limitRange 设计文档
和 LimitRange 例子
以了解更多细节。
MutatingAdmissionWebhook
该准入控制器调用任何与请求匹配的变更 Webhook。匹配的 Webhook 将被串行调用。
每一个 Webhook 都可以根据需要修改对象。
MutatingAdmissionWebhook
,顾名思义,仅在变更阶段运行。
如果由此准入控制器调用的 Webhook 有副作用(如降低配额),
则它 必须 具有协调系统,因为不能保证后续的 Webhook 和验证准入控制器都会允许完成请求。
如果你禁用了 MutatingAdmissionWebhook,那么还必须使用 --runtime-config
标志禁止
admissionregistration.k8s.io/v1
组/版本中的 MutatingWebhookConfiguration
对象(版本 >=1.9 时,这两个对象都是默认启用的)。
谨慎编写和安装变更 webhook
当用户尝试创建的对象与返回的对象不同时,用户可能会感到困惑。
当它们回读的对象与尝试创建的对象不同,内建的控制环可能会出问题。
与覆盖原始请求中设置的字段相比,使用原始请求未设置的字段会引起问题的可能性较小。
应尽量避免前面那种方式。
内建资源和第三方资源的控制回路未来可能会受到破坏性的更改,使现在运行良好的 Webhook
无法再正常运行。即使完成了 Webhook API 安装,也不代表会为该 webhook 提供无限期的支持。
NamespaceAutoProvision
该准入控制器会检查名字空间资源上的所有传入请求,并检查所引用的名字空间是否确实存在。
如果找不到,它将创建一个名字空间。
此准入控制器对于不想要求名字空间必须先创建后使用的集群部署中很有用。
NamespaceExists
该准入控制器检查除 Namespace
以外的名字空间作用域资源上的所有请求。
如果请求引用的名字空间不存在,则拒绝该请求。
NamespaceLifecycle
该准入控制器禁止在一个正在被终止的 Namespace
中创建新对象,并确保
使用不存在的 Namespace
的请求被拒绝。
该准入控制器还会禁止删除三个系统保留的名字空间,即 default
、
kube-system
和 kube-public
。
删除 Namespace
会触发删除该名字空间中所有对象(Pod、Service 等)的一系列操作。
为了确保这个过程的完整性,我们强烈建议启用这个准入控制器。
NodeRestriction
该准入控制器限制了 kubelet 可以修改的 Node
和 Pod
对象。
为了受到这个准入控制器的限制,kubelet 必须使用在 system:nodes
组中的凭证,
并使用 system:node:<nodeName>
形式的用户名。
这样,kubelet 只可修改自己的 Node
API 对象,只能修改绑定到节点本身的 Pod 对象。
在 Kubernetes 1.11+ 的版本中,不允许 kubelet 从 Node
API 对象中更新或删除污点。
在 Kubernetes 1.13+ 的版本中,NodeRestriction
准入插件可防止 kubelet 删除
Node
API 对象,并对 kubernetes.io/
或 k8s.io/
前缀标签的 kubelet
强制进行如下修改:
防止 kubelet 添加/删除/更新带有 node-restriction.kubernetes.io/
前缀的标签。
保留此前缀的标签,供管理员用来标记 Node 对象以隔离工作负载,并且不允许 kubelet
修改带有该前缀的标签。
允许 kubelet 添加/删除/更新这些和这些前缀的标签:
kubernetes.io/hostname
kubernetes.io/arch
kubernetes.io/os
beta.kubernetes.io/instance-type
node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/region
(已弃用)
failure-domain.beta.kubernetes.io/zone
(已弃用)
topology.kubernetes.io/region
topology.kubernetes.io/zone
kubelet.kubernetes.io/
-prefixed labels
node.kubernetes.io/
-prefixed labels
kubelet 保留 kubernetes.io
或 k8s.io
前缀的所有标签,并且将来可能会被
NodeRestriction
准入插件允许或禁止。
将来的版本可能会增加其他限制,以确保 kubelet 具有正常运行所需的最小权限集。
OwnerReferencesPermissionEnforcement
该准入控制器保护对 metadata.ownerReferences
对象的访问,以便只有对该对象具有
“删除” 权限的用户才能对其进行更改。
该准入控制器还保护对 metadata.ownerReferences[x].blockOwnerDeletion
对象的访问,
以便只有对所引用的 属主(owner) 的 finalizers
子资源具有 “更新”
权限的用户才能对其进行更改。
PersistentVolumeClaimResize
该准入控制器检查传入的 PersistentVolumeClaim
调整大小请求,对其执行额外的验证操作。
说明:
对调整卷大小的支持是一种 Beta 特性。作为集群管理员,你必须确保特性门控 ExpandPersistentVolumes
设置为 true
才能启用调整大小。
启用 ExpandPersistentVolumes
特性门控之后,建议将 PersistentVolumeClaimResize
准入控制器也启用。除非 PVC 的 StorageClass
明确地将 allowVolumeExpansion
设置为
true
来显式启用调整大小。否则,默认情况下该准入控制器会阻止所有对 PVC 大小的调整。
例如:由以下 StorageClass
创建的所有 PersistentVolumeClaim
都支持卷容量扩充:
apiVersion : storage.k8s.io/v1
kind : StorageClass
metadata :
name : gluster-vol-default
provisioner : kubernetes.io/glusterfs
parameters :
resturl : "http://192.168.10.100:8080"
restuser : ""
secretNamespace : ""
secretName : ""
allowVolumeExpansion : true
关于持久化卷申领的更多信息,请参见
PersistentVolumeClaims 。
PersistentVolumeLabel
FEATURE STATE: Kubernetes v1.13 [deprecated]
该准入控制器会自动将区(region)或区域(zone)标签附加到由云提供商(如 GCE、AWS)
定义的 PersistentVolume。这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。
如果准入控制器不支持为 PersistentVolumes 自动添加标签,那你可能需要手动添加标签,
以防止 Pod 挂载其他区域的卷。
PersistentVolumeLabel 已被废弃,标记持久卷已由
云管理控制器 接管。
从 1.11 开始,默认情况下禁用此准入控制器。
PodNodeSelector
FEATURE STATE: Kubernetes v1.5 [alpha]
该准入控制器通过读取名字空间注解和全局配置,来为名字空间中可以使用的节点选择器
设置默认值并实施限制。
配置文件格式
PodNodeSelector
使用配置文件来设置后端行为的选项。
请注意,配置文件格式将在将来某个版本中改为版本化文件。
该文件可以是 JSON 或 YAML,格式如下:
podNodeSelectorPluginConfig :
clusterDefaultNodeSelector : name-of-node-selector
namespace1 : name-of-node-selector
namespace2 : name-of-node-selector
基于提供给 API 服务器命令行标志 --admission-control-config-file
的文件名,
从文件中引用 PodNodeSelector
配置文件:
apiVersion : apiserver.config.k8s.io/v1
kind : AdmissionConfiguration
plugins :
- name : PodNodeSelector
path : podnodeselector.yaml
...
# 在 v1.17 中废弃,以鼓励使用 apiserver.config.k8s.io/v1
apiVersion : apiserver.k8s.io/v1alpha1
kind : AdmissionConfiguration
plugins :
- name : PodNodeSelector
path : podnodeselector.yaml
...
配置注解格式
PodNodeSelector
使用键为 scheduler.alpha.kubernetes.io/node-selector
的注解
为名字空间设置节点选择算符。
apiVersion : v1
kind : Namespace
metadata :
annotations :
scheduler.alpha.kubernetes.io/node-selector : name-of-node-selector
name : namespace3
内部行为
该准入控制器行为如下:
如果 Namespace
的注解带有键 scheduler.alpha.kubernetes.io/node-selector
,
则将其值用作节点选择算符。
如果名字空间缺少此类注解,则使用 PodNodeSelector
插件配置文件中定义的
clusterDefaultNodeSelector
作为节点选择算符。
评估 Pod 节点选择算符和名字空间节点选择算符是否存在冲突。存在冲突将导致拒绝。
评估 Pod 节点选择算符和特定于名字空间的被允许的选择算符所定义的插件配置文件是否存在冲突。
存在冲突将导致拒绝。
说明:
PodNodeSelector 允许 Pod 强制在特定标签的节点上运行。
另请参阅 PodTolerationRestriction 准入插件,该插件可防止 Pod 在特定污点的节点上运行。
PodSecurity
FEATURE STATE: Kubernetes v1.23 [beta]
这是下节已被废弃的 PodSecurityPolicy 准入控制器的替代品。
此准入控制器负责在创建和修改 Pod 时根据请求的安全上下文和
Pod 安全标准
来确定是否可以执行请求。
更多信息请参阅 Pod 安全性准入控制器 。
PodSecurityPolicy
FEATURE STATE: Kubernetes v1.21 [deprecated]
此准入控制器负责在创建和修改 Pod 时根据请求的安全上下文和可用的 Pod
安全策略确定是否可以执行请求。
查看 Pod 安全策略文档
了解更多细节。
PodTolerationRestriction
FEATURE STATE: Kubernetes v1.7 [alpha]
准入控制器 PodTolerationRestriction 检查 Pod 的容忍度与其名字空间的容忍度之间
是否存在冲突。如果存在冲突,则拒绝 Pod 请求。
然后,它将名字空间的容忍度合并到 Pod 的容忍度中,之后根据名字空间的容忍度
白名单检查所得到的容忍度结果。如果检查成功,则将接受 Pod 请求,否则拒绝该请求。
如果 Pod 的名字空间没有任何关联的默认容忍度或容忍度白名单,则使用集群级别的
默认容忍度或容忍度白名单(如果有的话)。
名字空间的容忍度通过注解健 scheduler.alpha.kubernetes.io/defaultTolerations
来设置。可接受的容忍度可以通过 scheduler.alpha.kubernetes.io/tolerationsWhitelist
注解键来添加。
名字空间注解的示例:
apiVersion : v1
kind : Namespace
metadata :
name : apps-that-need-nodes-exclusively
annotations :
scheduler.alpha.kubernetes.io/defaultTolerations : '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'
scheduler.alpha.kubernetes.io/tolerationsWhitelist : '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'
优先级
优先级准入控制器使用 priorityClassName
字段并用整型值填充优先级。
如果找不到优先级,则拒绝 Pod。
ResourceQuota
该准入控制器会监测传入的请求,并确保它不违反任何一个 Namespace
中的 ResourceQuota
对象中枚举出来的约束。
如果你在 Kubernetes 部署中使用了 ResourceQuota
,你必须使用这个准入控制器来强制
执行配额限制。
请查看
resourceQuota 设计文档 和 Resource Quota 例子
了解更多细节。
RuntimeClass
+
FEATURE STATE: Kubernetes v1.20 [stable]
如果你开启 PodOverhead
特性门控 ,
并且通过 Pod 开销
配置来定义一个 RuntimeClass,这个准入控制器会检查新的 Pod。
当启用的时候,这个准入控制器会拒绝任何 overhead 字段已经设置的 Pod。
对于配置了 RuntimeClass 并在其 .spec
中选定 RuntimeClass 的 Pod,
此准入控制器会根据相应 RuntimeClass 中定义的值为 Pod 设置 .spec.overhead
。
说明: Pod 的 .spec.overhead
字段和 RuntimeClass 的 .overhead
字段均为处于 beta 版本。
如果你未启用 PodOverhead
特性门控,则所有 Pod 均被视为未设置 .spec.overhead
。
详情请参见 Pod 开销 。
SecurityContextDeny
该准入控制器将拒绝任何试图设置特定提升
SecurityContext
字段的 Pod,正如任务
为 Pod 或 Container 配置安全上下文
中所展示的那样。
如果集群没有使用 Pod 安全策略
来限制安全上下文所能获取的值集,那么应该启用这个功能。
ServiceAccount
此准入控制器实现了
ServiceAccount
的自动化。
如果你打算使用 Kubernetes 的 ServiceAccount 对象,我们强烈建议你使用这个准入控制器。
StorageObjectInUseProtection
StorageObjectInUseProtection
插件将 kubernetes.io/pvc-protection
或
kubernetes.io/pv-protection
finalizers 添加到新创建的持久化卷声明(PVC)
或持久化卷(PV)中。
如果用户尝试删除 PVC/PV,除非 PVC/PV 的保护控制器移除 finalizers,否则
PVC/PV 不会被删除。
有关更多详细信息,请参考
保护使用中的存储对象 。
TaintNodesByCondition
FEATURE STATE: Kubernetes v1.17 [stable]
该准入控制器为新创建的节点添加 NotReady
和 NoSchedule
污点 。
这些污点能够避免一些竞态条件的发生,这类静态条件可能导致 Pod 在更新节点污点以准确
反映其所报告状况之前,就被调度到新节点上。
ValidatingAdmissionWebhook
该准入控制器调用与请求匹配的所有验证 Webhook。
匹配的 Webhook 将被并行调用。如果其中任何一个拒绝请求,则整个请求将失败。
该准入控制器仅在验证(Validating)阶段运行;与 MutatingAdmissionWebhook
准入控制器
所调用的 Webhook 相反,它调用的 Webhook 应该不会使对象出现变更。
如果以此方式调用的 Webhook 有其它作用(如,降低配额),则它必须具有协调机制。
这是因为无法保证后续的 Webhook 或其他有效的准入控制器都允许请求完成。
如果你禁用了 ValidatingAdmissionWebhook,还必须通过 --runtime-config
标志来禁用
admissionregistration.k8s.io/v1
组/版本中的 ValidatingWebhookConfiguration
对象(默认情况下在 1.9 版和更高版本中均处于启用状态)。
有推荐的准入控制器吗?
有。推荐使用的准入控制器默认情况下都处于启用状态
(请查看这里 )。
因此,你无需显式指定它们。
你可以使用 --enable-admission-plugins
标志( 顺序不重要 )来启用默认设置以外的其他准入控制器。
说明:
--admission-control
在 1.10 中已废弃,由 --enable-admission-plugins
取代。
3.5 - 动态准入控制
除了内置的 admission 插件 ,
准入插件可以作为扩展独立开发,并以运行时所配置的 Webhook 的形式运行。
此页面描述了如何构建、配置、使用和监视准入 Webhook。
什么是准入 Webhook?
准入 Webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。
可以定义两种类型的准入 webhook,即
验证性质的准入 Webhook 和
修改性质的准入 Webhook 。
修改性质的准入 Webhook 会先被调用。它们可以更改发送到 API
服务器的对象以执行自定义的设置默认值操作。
在完成了所有对象修改并且 API 服务器也验证了所传入的对象之后,
验证性质的 Webhook 会被调用,并通过拒绝请求的方式来强制实施自定义的策略。
说明: 如果准入 Webhook 需要保证它们所看到的是对象的最终状态以实施某种策略。
则应使用验证性质的准入 Webhook,因为对象被修改性质 Webhook 看到之后仍然可能被修改。
尝试准入 Webhook
准入 Webhook 本质上是集群控制平面的一部分。你应该非常谨慎地编写和部署它们。
如果你打算编写或者部署生产级准入 webhook,请阅读用户指南 以获取相关说明。
在下文中,我们将介绍如何快速试验准入 Webhook。
先决条件
确保 Kubernetes 集群版本至少为 v1.16(以便使用 admissionregistration.k8s.io/v1
API) 或者 v1.9 (以便使用 admissionregistration.k8s.io/v1beta1
API)。
确保启用 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 控制器。
这里
是一组推荐的 admission 控制器,通常可以启用。
确保启用了 admissionregistration.k8s.io/v1beta1
API。
编写一个准入 Webhook 服务器
请参阅 Kubernetes e2e 测试中的
admission webhook 服务器
的实现。webhook 处理由 apiserver 发送的 AdmissionReview
请求,并且将其决定
作为 AdmissionReview
对象以相同版本发送回去。
有关发送到 webhook 的数据的详细信息,请参阅 webhook 请求 。
要获取来自 webhook 的预期数据,请参阅 webhook 响应 。
示例准入 Webhook 服务器置 ClientAuth
字段为
空 ,
默认为 NoClientCert
。这意味着 webhook 服务器不会验证客户端的身份,认为其是 apiservers。
如果你需要双向 TLS 或其他方式来验证客户端,请参阅
如何对 apiservers 进行身份认证 。
部署准入 Webhook 服务
e2e 测试中的 webhook 服务器通过
deployment API
部署在 Kubernetes 集群中。该测试还将创建一个
service
作为 webhook 服务器的前端。参见
相关代码 。
你也可以在集群外部署 webhook。这样做需要相应地更新你的 webhook 配置。
即时配置准入 Webhook
你可以通过
ValidatingWebhookConfiguration
或者
MutatingWebhookConfiguration 动态配置哪些资源要被哪些准入 Webhook 处理。
以下是一个 ValidatingWebhookConfiguration
示例,mutating webhook 配置与此类似。有关每个配置字段的详细信息,请参阅 webhook 配置 部分。
apiVersion : admissionregistration.k8s.io/v1
kind : ValidatingWebhookConfiguration
metadata :
name : "pod-policy.example.com"
webhooks :
- name : "pod-policy.example.com"
rules :
- apiGroups : ["" ]
apiVersions : ["v1" ]
operations : ["CREATE" ]
resources : ["pods" ]
scope : "Namespaced"
clientConfig :
service :
namespace : "example-namespace"
name : "example-service"
caBundle : "Ci0tLS0tQk...<base64-encoded PEM bundle containing the CA that signed the webhook's serving certificate>...tLS0K"
admissionReviewVersions : ["v1" , "v1beta1" ]
sideEffects : None
timeoutSeconds : 5
# 1.16 中被淘汰,推荐使用 admissionregistration.k8s.io/v1
apiVersion : admissionregistration.k8s.io/v1beta1
kind : ValidatingWebhookConfiguration
metadata :
name : "pod-policy.example.com"
webhooks :
- name : "pod-policy.example.com"
rules :
- apiGroups : ["" ]
apiVersions : ["v1" ]
operations : ["CREATE" ]
resources : ["pods" ]
scope : "Namespaced"
clientConfig :
service :
namespace : "example-namespace"
name : "example-service"
caBundle : "Ci0tLS0tQk...<base64-encoded PEM bundle containing the CA that signed the webhook's serving certificate>...tLS0K"
admissionReviewVersions : ["v1beta1" ]
timeoutSeconds : 5
scope 字段指定是仅集群范围的资源(Cluster)还是名字空间范围的资源资源(Namespaced)将与此规则匹配。*
表示没有范围限制。
说明: 当使用 clientConfig.service
时,服务器证书必须对 <svc_name>.<svc_namespace>.svc
有效。
说明: 对于使用 admissionregistration.k8s.io/v1
创建的 webhook 而言,其 webhook 调用的默认超时是 10 秒;
对于使用 admissionregistration.k8s.io/v1beta1
创建的 webhook 而言,其默认超时是 30 秒。
从 kubernetes 1.14 开始,可以设置超时。建议对 webhooks 设置较短的超时时间。
如果 webhook 调用超时,则根据 webhook 的失败策略处理请求。
当 apiserver 收到与 rules
相匹配的请求时,apiserver 按照 clientConfig
中指定的方式向 webhook 发送一个 admissionReview
请求。
创建 webhook 配置后,系统将花费几秒钟使新配置生效。
对 apiservers 进行身份认证
如果你的 webhook 需要身份验证,则可以将 apiserver 配置为使用基本身份验证、持有者令牌或证书来向 webhook 提供身份证明。完成此配置需要三个步骤。
启动 apiserver 时,通过 --admission-control-config-file
参数指定准入控制配置文件的位置。
在准入控制配置文件中,指定 MutatingAdmissionWebhook 控制器和 ValidatingAdmissionWebhook 控制器应该读取凭据的位置。
凭证存储在 kubeConfig 文件中(是的,与 kubectl 使用的模式相同),因此字段名称为 kubeConfigFile
。
以下是一个准入控制配置文件示例:
apiVersion : apiserver.config.k8s.io/v1
kind : AdmissionConfiguration
plugins :
- name : ValidatingAdmissionWebhook
configuration :
apiVersion : apiserver.config.k8s.io/v1
kind : WebhookAdmissionConfiguration
kubeConfigFile : "<path-to-kubeconfig-file>"
- name : MutatingAdmissionWebhook
configuration :
apiVersion : apiserver.config.k8s.io/v1
kind : WebhookAdmissionConfiguration
kubeConfigFile : "<path-to-kubeconfig-file>"
# 1.17 中被淘汰,推荐使用 apiserver.config.k8s.io/v1
apiVersion : apiserver.k8s.io/v1alpha1
kind : AdmissionConfiguration
plugins :
- name : ValidatingAdmissionWebhook
configuration :
# 1.17 中被淘汰,推荐使用 apiserver.config.k8s.io/v1,kind = WebhookAdmissionConfiguration
apiVersion : apiserver.config.k8s.io/v1alpha1
kind : WebhookAdmission
kubeConfigFile : "<path-to-kubeconfig-file>"
- name : MutatingAdmissionWebhook
configuration :
# 1.17 中被淘汰,推荐使用 apiserver.config.k8s.io/v1,kind = WebhookAdmissionConfiguration
apiVersion : apiserver.config.k8s.io/v1alpha1
kind : WebhookAdmission
kubeConfigFile : "<path-to-kubeconfig-file>"
有关 AdmissionConfiguration
的更多信息,请参见
AdmissionConfiguration (v1) reference 。
有关每个配置字段的详细信息,请参见 webhook 配置 部分。
在 kubeConfig 文件中,提供证书凭据:
apiVersion : v1
kind : Config
users :
# 名称应设置为服务的 DNS 名称或配置了 Webhook 的 URL 的主机名(包括端口)。
# 如果将非 443 端口用于服务,则在配置 1.16+ API 服务器时,该端口必须包含在名称中。
#
# 对于配置在默认端口(443)上与服务对话的 Webhook,请指定服务的 DNS 名称:
# - name: webhook1.ns1.svc
# user: ...
#
# 对于配置在非默认端口(例如 8443)上与服务对话的 Webhook,请在 1.16+ 中指定服务的 DNS 名称和端口:
# - name: webhook1.ns1.svc:8443
# user: ...
# 并可以选择仅使用服务的 DNS 名称来创建第二节,以与 1.15 API 服务器版本兼容:
# - name: webhook1.ns1.svc
# user: ...
#
# 对于配置为使用 URL 的 webhook,请匹配在 webhook 的 URL 中指定的主机(和端口)。
# 带有 `url: https://www.example.com` 的 webhook:
# - name: www.example.com
# user: ...
#
# 带有 `url: https://www.example.com:443` 的 webhook:
# - name: www.example.com:443
# user: ...
#
# 带有 `url: https://www.example.com:8443` 的 webhook:
# - name: www.example.com:8443
# user: ...
#
- name : 'webhook1.ns1.svc'
user :
client-certificate-data : "<pem encoded certificate>"
client-key-data : "<pem encoded key>"
# `name` 支持使用 * 通配符匹配前缀段。
- name : '*.webhook-company.org'
user :
password : "<password>"
username : "<name>"
# '*' 是默认匹配项。
- name : '*'
user :
token : "<token>"
当然,你需要设置 webhook 服务器来处理这些身份验证。
请求
Webhook 发送 POST 请求时,请设置 Content-Type: application/json
并对 admission.k8s.io
API 组中的 AdmissionReview
对象进行序列化,将所得到的 JSON 作为请求的主体。
Webhook 可以在配置中的 admissionReviewVersions
字段指定可接受的 AdmissionReview
对象版本:
apiVersion : admissionregistration.k8s.io/v1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
admissionReviewVersions : ["v1" , "v1beta1" ]
...
创建 admissionregistration.k8s.io/v1
webhook 配置时,admissionReviewVersions
是必填字段。
Webhook 必须支持至少一个当前和以前的 apiserver 都可以解析的 AdmissionReview
版本。
# v1.16 中被淘汰,推荐使用 admissionregistration.k8s.io/v1
apiVersion : admissionregistration.k8s.io/v1beta1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
admissionReviewVersions : ["v1beta1" ]
...
如果未指定 admissionReviewVersions
,则创建 admissionregistration.k8s.io/v1beta1
Webhook 配置时的默认值为 v1beta1
。
API 服务器将发送的是 admissionReviewVersions
列表中所支持的第一个 AdmissionReview
版本。如果 API 服务器不支持列表中的任何版本,则不允许创建配置。
如果 API 服务器遇到以前创建的 Webhook 配置,并且不支持该 API 服务器知道如何发送的任何 AdmissionReview
版本,则调用 Webhook 的尝试将失败,并依据失败策略 进行处理。
此示例显示了 AdmissionReview
对象中包含的数据,该数据用于请求更新 apps/v1
Deployment
的 scale
子资源:
{
"apiVersion": "admission.k8s.io/v1" ,
"kind": "AdmissionReview" ,
"request": {
# 唯一标识此准入回调的随机 uid
"uid": "705ab4f5-6393-11e8-b7cc-42010a800002" ,
# 传入完全正确的 group/version/kind 对象
"kind": {"group" :"autoscaling" ,"version" :"v1" ,"kind" :"Scale" },
# 修改 resource 的完全正确的的 group/version/kind
"resource": {"group" :"apps" ,"version" :"v1" ,"resource" :"deployments" },
# subResource(如果请求是针对 subResource 的)
"subResource": "scale" ,
# 在对 API 服务器的原始请求中,传入对象的标准 group/version/kind
# 仅当 webhook 指定 `matchPolicy: Equivalent` 且将对 API 服务器的原始请求转换为 webhook 注册的版本时,这才与 `kind` 不同。
"requestKind": {"group" :"autoscaling" ,"version" :"v1" ,"kind" :"Scale" },
# 在对 API 服务器的原始请求中正在修改的资源的标准 group/version/kind
# 仅当 webhook 指定了 `matchPolicy:Equivalent` 并且将对 API 服务器的原始请求转换为 webhook 注册的版本时,这才与 `resource` 不同。
"requestResource": {"group" :"apps" ,"version" :"v1" ,"resource" :"deployments" },
# subResource(如果请求是针对 subResource 的)
# 仅当 webhook 指定了 `matchPolicy:Equivalent` 并且将对 API 服务器的原始请求转换为该 webhook 注册的版本时,这才与 `subResource` 不同。
"requestSubResource": "scale" ,
# 被修改资源的名称
"name": "my-deployment" ,
# 如果资源是属于名字空间(或者是名字空间对象),则这是被修改的资源的名字空间
"namespace": "my-namespace" ,
# 操作可以是 CREATE、UPDATE、DELETE 或 CONNECT
"operation": "UPDATE" ,
"userInfo": {
# 向 API 服务器发出请求的经过身份验证的用户的用户名
"username": "admin" ,
# 向 API 服务器发出请求的经过身份验证的用户的 UID
"uid": "014fbff9a07c" ,
# 向 API 服务器发出请求的经过身份验证的用户的组成员身份
"groups": ["system:authenticated" ,"my-admin-group" ],
# 向 API 服务器发出请求的用户相关的任意附加信息
# 该字段由 API 服务器身份验证层填充,并且如果 webhook 执行了任何 SubjectAccessReview 检查,则应将其包括在内。
"extra": {
"some-key" :["some-value1" , "some-value2" ]
}
},
# object 是被接纳的新对象。
# 对于 DELETE 操作,它为 null。
"object": {"apiVersion" :"autoscaling/v1" ,"kind" :"Scale" ,...},
# oldObject 是现有对象。
# 对于 CREATE 和 CONNECT 操作,它为 null。
"oldObject": {"apiVersion" :"autoscaling/v1" ,"kind" :"Scale" ,...},
# options 包含要接受的操作的选项,例如 meta.k8s.io/v CreateOptions、UpdateOptions 或 DeleteOptions。
# 对于 CONNECT 操作,它为 null。
"options": {"apiVersion" :"meta.k8s.io/v1" ,"kind" :"UpdateOptions" ,...},
# dryRun 表示 API 请求正在以 `dryrun` 模式运行,并且将不会保留。
# 带有副作用的 Webhook 应该避免在 dryRun 为 true 时激活这些副作用。
# 有关更多详细信息,请参见 http://k8s.io/docs/reference/using-api/api-concepts/#make-a-dry-run-request
"dryRun": false
}
}
{
# v1.16 中被废弃,推荐使用 admission.k8s.io/v1
"apiVersion": "admission.k8s.io/v1beta1" ,
"kind": "AdmissionReview" ,
"request": {
# 唯一标识此准入回调的随机 uid
"uid": "705ab4f5-6393-11e8-b7cc-42010a800002" ,
# 传入完全正确的 group/version/kind 对象
"kind": {"group" :"autoscaling" ,"version" :"v1" ,"kind" :"Scale" },
# 修改 resource 的完全正确的的 group/version/kind
"resource": {"group" :"apps" ,"version" :"v1" ,"resource" :"deployments" },
# subResource(如果请求是针对 subResource 的)
"subResource": "scale" ,
# 在对 API 服务器的原始请求中,传入对象的标准 group/version/kind。
# 仅当 Webhook 指定了 `matchPolicy:Equivalent` 并且将对 API 服务器的原始请求转换为该 Webhook 注册的版本时,这与 `kind` 不同。
# 仅由 v1.15+ API 服务器发送。
"requestKind": {"group" :"autoscaling" ,"version" :"v1" ,"kind" :"Scale" },
# 在对 API 服务器的原始请求中正在修改的资源的标准 group/version/kind
# 仅当 webhook 指定了 `matchPolicy:Equivalent` 并且将对 API 服务器的原始请求转换为 webhook 注册的版本时,这才与 `resource` 不同。
# 仅由 v1.15+ API 服务器发送。
"requestResource": {"group" :"apps" ,"version" :"v1" ,"resource" :"deployments" },
# subResource(如果请求是针对 subResource 的)
# 仅当 webhook 指定了 `matchPolicy:Equivalent` 并且将对 API 服务器的原始请求转换为该 webhook 注册的版本时,这才与 `subResource` 不同。
# 仅由 v1.15+ API 服务器发送。
"requestSubResource": "scale" ,
# 被修改资源的名称
"name": "my-deployment" ,
# 如果资源是属于名字空间(或者是名字空间对象),则这是被修改的资源的名字空间
"namespace": "my-namespace" ,
# 操作可以是 CREATE、UPDATE、DELETE 或 CONNECT
"operation": "UPDATE" ,
"userInfo": {
# 向 API 服务器发出请求的经过身份验证的用户的用户名
"username": "admin" ,
# 向 API 服务器发出请求的经过身份验证的用户的 UID
"uid": "014fbff9a07c" ,
# 向 API 服务器发出请求的经过身份验证的用户的组成员身份
"groups": ["system:authenticated" ,"my-admin-group" ],
# 向 API 服务器发出请求的用户相关的任意附加信息
# 该字段由 API 服务器身份验证层填充,并且如果 webhook 执行了任何 SubjectAccessReview 检查,则应将其包括在内。
"extra": {
"some-key" :["some-value1" , "some-value2" ]
}
},
# object 是被接纳的新对象。
# 对于 DELETE 操作,它为 null。
"object": {"apiVersion" :"autoscaling/v1" ,"kind" :"Scale" ,...},
# oldObject 是现有对象。
# 对于 CREATE 和 CONNECT 操作(对于 v1.15.0 之前版本的 API 服务器中的 DELETE 操作),它为 null。
"oldObject": {"apiVersion" :"autoscaling/v1" ,"kind" :"Scale" ,...},
# options 包含要接受的操作的选项,例如 meta.k8s.io/v CreateOptions、UpdateOptions 或 DeleteOptions。
# 对于 CONNECT 操作,它为 null。
# 仅由 v1.15+ API 服务器发送。
"options": {"apiVersion" :"meta.k8s.io/v1" ,"kind" :"UpdateOptions" ,...},
# dryRun 表示 API 请求正在以 `dryrun` 模式运行,并且将不会保留。
# 带有副作用的 Webhook 应该避免在 dryRun 为 true 时激活这些副作用。
# 有关更多详细信息,请参见 http://k8s.io/docs/reference/using-api/api-concepts/#make-a-dry-run-request
"dryRun": false
}
}
响应
Webhook 使用 HTTP 200 状态码、Content-Type: application/json
和一个包含 AdmissionReview
对象的 JSON 序列化格式来发送响应。该 AdmissionReview
对象与发送的版本相同,且其中包含的 response
字段已被有效填充。
response
至少必须包含以下字段:
uid
,从发送到 webhook 的 request.uid
中复制而来
allowed
,设置为 true
或 false
Webhook 允许请求的最简单响应示例:
{
"apiVersion" : "admission.k8s.io/v1" ,
"kind" : "AdmissionReview" ,
"response" : {
"uid" : "<value from request.uid>" ,
"allowed" : true
}
}
{
"apiVersion" : "admission.k8s.io/v1beta1" ,
"kind" : "AdmissionReview" ,
"response" : {
"uid" : "<value from request.uid>" ,
"allowed" : true
}
}
Webhook 禁止请求的最简单响应示例:
{
"apiVersion" : "admission.k8s.io/v1" ,
"kind" : "AdmissionReview" ,
"response" : {
"uid" : "<value from request.uid>" ,
"allowed" : false
}
}
{
"apiVersion" : "admission.k8s.io/v1beta1" ,
"kind" : "AdmissionReview" ,
"response" : {
"uid" : "<value from request.uid>" ,
"allowed" : false
}
}
当拒绝请求时,Webhook 可以使用 status
字段自定义 http 响应码和返回给用户的消息。
有关状态类型的详细信息,请参见
API 文档 。
禁止请求的响应示例,它定制了向用户显示的 HTTP 状态码和消息:
{
"apiVersion" : "admission.k8s.io/v1" ,
"kind" : "AdmissionReview" ,
"response" : {
"uid" : "<value from request.uid>" ,
"allowed" : false ,
"status" : {
"code" : 403 ,
"message" : "You cannot do this because it is Tuesday and your name starts with A"
}
}
}
{
"apiVersion" : "admission.k8s.io/v1beta1" ,
"kind" : "AdmissionReview" ,
"response" : {
"uid" : "<value from request.uid>" ,
"allowed" : false ,
"status" : {
"code" : 403 ,
"message" : "You cannot do this because it is Tuesday and your name starts with A"
}
}
}
当允许请求时,mutating准入 Webhook 也可以选择修改传入的对象。
这是通过在响应中使用 patch
和 patchType
字段来完成的。
当前唯一支持的 patchType
是 JSONPatch
。
有关更多详细信息,请参见 JSON patch 。
对于 patchType: JSONPatch
,patch
字段包含一个以 base64 编码的 JSON patch 操作数组。
例如,设置 spec.replicas
的单个补丁操作将是
[{"op": "add", "path": "/spec/replicas", "value": 3}]
。
如果以 Base64 形式编码,结果将是
W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0=
因此,添加该标签的 webhook 响应为:
{
"apiVersion" : "admission.k8s.io/v1" ,
"kind" : "AdmissionReview" ,
"response" : {
"uid" : "<value from request.uid>" ,
"allowed" : true ,
"patchType" : "JSONPatch" ,
"patch" : "W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0="
}
}
{
"apiVersion" : "admission.k8s.io/v1beta1" ,
"kind" : "AdmissionReview" ,
"response" : {
"uid" : "<value from request.uid>" ,
"allowed" : true ,
"patchType" : "JSONPatch" ,
"patch" : "W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0="
}
}
Webhook 配置
要注册准入 Webhook,请创建 MutatingWebhookConfiguration
或
ValidatingWebhookConfiguration
API 对象。
每种配置可以包含一个或多个 Webhook。如果在单个配置中指定了多个
Webhook,则应为每个 webhook 赋予一个唯一的名称。
这在 admissionregistration.k8s.io/v1
中是必需的,但是在使用
admissionregistration.k8s.io/v1beta1
时强烈建议使用,
以使生成的审核日志和指标更易于与活动配置相匹配。
每个 Webhook 定义以下内容。
匹配请求-规则
每个 webhook 必须指定用于确定是否应将对 apiserver 的请求发送到 webhook 的规则列表。
每个规则都指定一个或多个 operations、apiGroups、apiVersions 和 resources 以及资源的 scope:
operations
列出一个或多个要匹配的操作。
可以是 CREATE
、UPDATE
、DELETE
、CONNECT
或 *
以匹配所有内容。
apiGroups
列出了一个或多个要匹配的 API 组。""
是核心 API 组。"*"
匹配所有 API 组。
apiVersions
列出了一个或多个要匹配的 API 版本。"*"
匹配所有 API 版本。
resources
列出了一个或多个要匹配的资源。
"*"
匹配所有资源,但不包括子资源。
"*/*"
匹配所有资源,包括子资源。
"pods/*"
匹配 pod 的所有子资源。
"*/status"
匹配所有 status 子资源。
scope
指定要匹配的范围。有效值为 "Cluster"
、"Namespaced"
和 "*"
。
子资源匹配其父资源的范围。在 Kubernetes v1.14+ 版本中才被支持。
默认值为 "*"
,对应 1.14 版本之前的行为。
"Cluster"
表示只有集群作用域的资源才能匹配此规则(API 对象 Namespace 是集群作用域的)。
"Namespaced"
意味着仅具有名字空间的资源才符合此规则。
"*"
表示没有范围限制。
如果传入请求与任何 Webhook 规则的指定操作、组、版本、资源和范围匹配,则该请求将发送到 Webhook。
以下是可用于指定应拦截哪些资源的规则的其他示例。
匹配针对 apps/v1
和 apps/v1beta1
组中 deployments
和 replicasets
资源的 CREATE
或 UPDATE
请求:
apiVersion : admissionregistration.k8s.io/v1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
rules :
- operations : ["CREATE" , "UPDATE" ]
apiGroups : ["apps" ]
apiVersions : ["v1" , "v1beta1" ]
resources : ["deployments" , "replicasets" ]
scope : "Namespaced"
...
# v1.16 中被废弃,推荐使用 admissionregistration.k8s.io/v1
apiVersion : admissionregistration.k8s.io/v1beta1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
rules :
- operations : ["CREATE" , "UPDATE" ]
apiGroups : ["apps" ]
apiVersions : ["v1" , "v1beta1" ]
resources : ["deployments" , "replicasets" ]
scope : "Namespaced"
...
匹配所有 API 组和版本中的所有资源(但不包括子资源)的创建请求:
apiVersion : admissionregistration.k8s.io/v1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
rules :
- operations : ["CREATE" ]
apiGroups : ["*" ]
apiVersions : ["*" ]
resources : ["*" ]
scope : "*"
...
# v1.16 中被废弃,推荐使用 admissionregistration.k8s.io/v1
apiVersion : admissionregistration.k8s.io/v1beta1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
rules :
- operations : ["CREATE" ]
apiGroups : ["*" ]
apiVersions : ["*" ]
resources : ["*" ]
scope : "*"
...
匹配所有 API 组和版本中所有 status
子资源的更新请求:
apiVersion : admissionregistration.k8s.io/v1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
rules :
- operations : ["UPDATE" ]
apiGroups : ["*" ]
apiVersions : ["*" ]
resources : ["*/status" ]
scope : "*"
...
# v1.16 中被废弃,推荐使用 admissionregistration.k8s.io/v1
apiVersion : admissionregistration.k8s.io/v1beta1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
rules :
- operations : ["UPDATE" ]
apiGroups : ["*" ]
apiVersions : ["*" ]
resources : ["*/status" ]
scope : "*"
...
匹配请求:objectSelector
在版本 v1.15+ 中, 通过指定 objectSelector
,Webhook 能够根据
可能发送的对象的标签来限制哪些请求被拦截。
如果指定,则将对 objectSelector
和可能发送到 Webhook 的 object 和 oldObject
进行评估。如果两个对象之一与选择器匹配,则认为该请求已匹配。
空对象(对于创建操作而言为 oldObject,对于删除操作而言为 newObject),
或不能带标签的对象(例如 DeploymentRollback
或 PodProxyOptions
对象)
被认为不匹配。
仅当选择使用 webhook 时才使用对象选择器,因为最终用户可以通过设置标签来
跳过准入 Webhook。
这个例子展示了一个 mutating webhook,它将匹配带有标签 foo:bar
的任何资源的
CREATE
的操作:
apiVersion : admissionregistration.k8s.io/v1
kind : MutatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
objectSelector :
matchLabels :
foo : bar
rules :
- operations : ["CREATE" ]
apiGroups : ["*" ]
apiVersions : ["*" ]
resources : ["*" ]
scope : "*"
...
# v1.16 中被废弃,推荐使用 admissionregistration.k8s.io/v1
apiVersion : admissionregistration.k8s.io/v1beta1
kind : MutatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
objectSelector :
matchLabels :
foo : bar
rules :
- operations : ["CREATE" ]
apiGroups : ["*" ]
apiVersions : ["*" ]
resources : ["*" ]
scope : "*"
...
有关标签选择器的更多示例,请参见标签 。
匹配请求:namespaceSelector
通过指定 namespaceSelector
,Webhook 可以根据具有名字空间的资源所处的
名字空间的标签来选择拦截哪些资源的操作。
namespaceSelector
根据名字空间的标签是否匹配选择器,决定是否针对具名字空间的资源
(或 Namespace 对象)的请求运行 webhook。
如果对象是除 Namespace 以外的集群范围的资源,则 namespaceSelector
标签无效。
本例给出的修改性质的 Webhook 将匹配到对名字空间中具名字空间的资源的 CREATE
请求,
前提是这些资源不含值为 "0" 或 "1" 的 "runlevel" 标签:
apiVersion : admissionregistration.k8s.io/v1
kind : MutatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
namespaceSelector :
matchExpressions :
- key : runlevel
operator : NotIn
values : ["0" ,"1" ]
rules :
- operations : ["CREATE" ]
apiGroups : ["*" ]
apiVersions : ["*" ]
resources : ["*" ]
scope : "Namespaced"
...
# v1.16 中被废弃,推荐使用 admissionregistration.k8s.io/v1
apiVersion : admissionregistration.k8s.io/v1beta1
kind : MutatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
namespaceSelector :
matchExpressions :
- key : runlevel
operator : NotIn
values : ["0" ,"1" ]
rules :
- operations : ["CREATE" ]
apiGroups : ["*" ]
apiVersions : ["*" ]
resources : ["*" ]
scope : "Namespaced"
...
此示例显示了一个验证性质的 Webhook,它将匹配到对某名字空间中的任何具名字空间的资源的
CREATE
请求,前提是该名字空间具有值为 "prod" 或 "staging" 的 "environment" 标签:
apiVersion : admissionregistration.k8s.io/v1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
namespaceSelector :
matchExpressions :
- key : environment
operator : In
values : ["prod" ,"staging" ]
rules :
- operations : ["CREATE" ]
apiGroups : ["*" ]
apiVersions : ["*" ]
resources : ["*" ]
scope : "Namespaced"
...
# v1.16 中被废弃,推荐使用 admissionregistration.k8s.io/v1
apiVersion : admissionregistration.k8s.io/v1beta1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
namespaceSelector :
matchExpressions :
- key : environment
operator : In
values : ["prod" ,"staging" ]
rules :
- operations : ["CREATE" ]
apiGroups : ["*" ]
apiVersions : ["*" ]
resources : ["*" ]
scope : "Namespaced"
...
有关标签选择器的更多示例,请参见
标签 。
匹配请求:matchPolicy
API 服务器可以通过多个 API 组或版本来提供对象。
例如,Kubernetes API 服务器允许通过 extensions/v1beta1
、apps/v1beta1
、
apps/v1beta2
和 apps/v1
API 创建和修改 Deployment
对象。
例如,如果一个 webhook 仅为某些 API 组/版本指定了规则(例如
apiGroups:["apps"], apiVersions:["v1","v1beta1"]
),而修改资源的请求
是通过另一个 API 组/版本(例如 extensions/v1beta1
)发出的,
该请求将不会被发送到 Webhook。
在 v1.15+ 中,matchPolicy
允许 webhook 定义如何使用其 rules
匹配传入的请求。
允许的值为 Exact
或 Equivalent
。
Exact
表示仅当请求与指定规则完全匹配时才应拦截该请求。
Equivalent
表示如果某个请求意在修改 rules
中列出的资源,
即使该请求是通过其他 API 组或版本发起,也应拦截该请求。
在上面给出的示例中,仅为 apps/v1
注册的 webhook 可以使用 matchPolicy
:
matchPolicy: Exact
表示不会将 extensions/v1beta1
请求发送到 Webhook
matchPolicy:Equivalent
表示将 extensions/v1beta1
请求发送到 webhook
(将对象转换为 webhook 指定的版本:apps/v1
)
建议指定 Equivalent
,确保升级后启用 API 服务器中资源的新版本时,
Webhook 继续拦截他们期望的资源。
当 API 服务器停止提供某资源时,该资源不再被视为等同于该资源的其他仍在提供服务的版本。
例如,extensions/v1beta1
中的 Deployment 已被废弃,计划在 v1.16 中默认停止使用。
在这种情况下,带有 apiGroups:["extensions"], apiVersions:["v1beta1"], resources: ["deployments"]
规则的 Webhook 将不再拦截通过 apps/v1
API 来创建 Deployment 的请求。
["deployments"] 规则将不再拦截通过 apps/v1
API 创建的部署。
此示例显示了一个验证性质的 Webhook,该 Webhook 拦截对 Deployment 的修改(无论 API 组或版本是什么),
始终会发送一个 apps/v1
版本的 Deployment 对象:
apiVersion : admissionregistration.k8s.io/v1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
matchPolicy : Equivalent
rules :
- operations : ["CREATE" ,"UPDATE" ,"DELETE" ]
apiGroups : ["apps" ]
apiVersions : ["v1" ]
resources : ["deployments" ]
scope : "Namespaced"
...
使用 admissionregistration.k8s.io/v1
创建的 admission webhhok 默认为 Equivalent
。
# v1.16 中被废弃,推荐使用 admissionregistration.k8s.io/v1
apiVersion : admissionregistration.k8s.io/v1beta1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
matchPolicy : Equivalent
rules :
- operations : ["CREATE" ,"UPDATE" ,"DELETE" ]
apiGroups : ["apps" ]
apiVersions : ["v1" ]
resources : ["deployments" ]
scope : "Namespaced"
...
使用 admissionregistration.k8s.io/v1beta1
创建的准入 Webhook 默认为 Exact
。
调用 Webhook
API 服务器确定请求应发送到 webhook 后,它需要知道如何调用 webhook。
此信息在 webhook 配置的 clientConfig
节中指定。
Webhook 可以通过 URL 或服务引用来调用,并且可以选择包含自定义 CA 包,以用于验证 TLS 连接。
URL
url
以标准 URL 形式给出 webhook 的位置(scheme://host:port/path
)。
host
不应引用集群中运行的服务;通过指定 service
字段来使用服务引用。
主机可以通过某些 apiserver 中的外部 DNS 进行解析。
(例如,kube-apiserver
无法解析集群内 DNS,因为这将违反分层规则)。host
也可以是 IP 地址。
请注意,将 localhost
或 127.0.0.1
用作 host
是有风险的,
除非你非常小心地在所有运行 apiserver 的、可能需要对此 webhook
进行调用的主机上运行。这样的安装方式可能不具有可移植性,即很难在新集群中启用。
scheme 必须为 "https";URL 必须以 "https://" 开头。
使用用户或基本身份验证(例如:"user:password@")是不允许的。
使用片段("#...")和查询参数("?...")也是不允许的。
这是配置为调用 URL 的修改性质的 Webhook 的示例
(并且期望使用系统信任根证书来验证 TLS 证书,因此不指定 caBundle):
apiVersion : admissionregistration.k8s.io/v1
kind : MutatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
clientConfig :
url : "https://my-webhook.example.com:9443/my-webhook-path"
...
# v1.16 中被废弃,推荐使用 admissionregistration.k8s.io/v1
apiVersion : admissionregistration.k8s.io/v1beta1
kind : MutatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
clientConfig :
url : "https://my-webhook.example.com:9443/my-webhook-path"
...
服务引用
clientConfig
内部的 Service 是对该 Webhook 服务的引用。
如果 Webhook 在集群中运行,则应使用 service
而不是 url
。
服务的 namespace
和 name
是必需的。
port
是可选的,默认值为 443。path
是可选的,默认为 "/"。
这是一个 mutating Webhook 的示例,该 mutating Webhook 配置为在子路径 "/my-path" 端口
"1234" 上调用服务,并使用自定义 CA 包针对 ServerName
my-service-name.my-service-namespace.svc
验证 TLS 连接:
apiVersion : admissionregistration.k8s.io/v1
kind : MutatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
clientConfig :
caBundle : "Ci0tLS0tQk...<base64-encoded PEM bundle containing the CA that signed the webhook's serving certificate>...tLS0K"
service :
namespace : my-service-namespace
name : my-service-name
path : /my-path
port : 1234
...
# v1.16 中被废弃,推荐使用 admissionregistration.k8s.io/v1
apiVersion : admissionregistration.k8s.io/v1beta1
kind : MutatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
clientConfig :
caBundle : "Ci0tLS0tQk...<base64-encoded PEM bundle containing the CA that signed the webhook's serving certificate>...tLS0K"
service :
namespace : my-service-namespace
name : my-service-name
path : /my-path
port : 1234
...
副作用
Webhook 通常仅对发送给他们的 AdmissionReview
内容进行操作。
但是,某些 Webhook 在处理 admission 请求时会进行带外更改。
进行带外更改的(产生“副作用”的) Webhook 必须具有协调机制(如控制器),
该机制定期确定事物的实际状态,并调整由准入 Webhook 修改的带外数据以反映现实情况。
这是因为对准入 Webhook 的调用不能保证所准入的对象将原样保留,或根本不保留。
以后,webhook 可以修改对象的内容,在写入存储时可能会发生冲突,或者
服务器可以在持久保存对象之前关闭电源。
此外,处理 dryRun: true
admission 请求时,具有副作用的 Webhook 必须避免产生副作用。
一个 Webhook 必须明确指出在使用 dryRun
运行时不会有副作用,
否则 dry-run
请求将不会发送到该 Webhook,而 API 请求将会失败。
Webhook 使用 webhook 配置中的 sideEffects
字段显示它们是否有副作用:
Unknown
:有关调用 Webhook 的副作用的信息是不可知的。
如果带有 dryRun:true
的请求将触发对该 Webhook 的调用,则该请求将失败,并且不会调用该 Webhook。
None
:调用 webhook 没有副作用。
Some
:调用 webhook 可能会有副作用。
如果请求具有 dry-run
属性将触发对此 Webhook 的调用,
则该请求将会失败,并且不会调用该 Webhook。
NoneOnDryRun
:调用 webhook 可能会有副作用,但是如果将带有 dryRun: true
属性的请求发送到 webhook,则 webhook 将抑制副作用(该 webhook 可识别 dryRun
)。
允许值:
在 admissionregistration.k8s.io/v1beta1
中,sideEffects
可以设置为
Unknown
、None
、Some
或者 NoneOnDryRun
,并且默认值为 Unknown
。
在 admissionregistration.k8s.io/v1
中, sideEffects
必须设置为
None
或者 NoneOnDryRun
。
这是一个 validating webhook 的示例,表明它对 dryRun: true
请求没有副作用:
apiVersion : admissionregistration.k8s.io/v1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
sideEffects : NoneOnDryRun
...
# v1.16 中被废弃,推荐使用 admissionregistration.k8s.io/v1
apiVersion : admissionregistration.k8s.io/v1beta1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
sideEffects : NoneOnDryRun
...
超时
由于 Webhook 会增加 API 请求的延迟,因此应尽快完成自身的操作。
timeoutSeconds
用来配置在将调用视为失败之前,允许 API 服务器等待 Webhook 响应的时间长度。
如果超时在 Webhook 响应之前被触发,则基于失败策略 ,将忽略
Webhook 调用或拒绝 API 调用。
超时值必须设置在 1 到 30 秒之间。
这是一个自定义超时设置为 2 秒的 validating Webhook 的示例:
apiVersion : admissionregistration.k8s.io/v1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
timeoutSeconds : 2
...
使用 admissionregistration.k8s.io/v1
创建的准入 Webhook 默认超时为 10 秒。
# v1.16 中被废弃,推荐使用 admissionregistration.k8s.io/v1
apiVersion : admissionregistration.k8s.io/v1beta1
kind : ValidatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
timeoutSeconds : 2
...
使用 admissionregistration.k8s.io/v1beta1
创建的准入 Webhook 默认超时为 30 秒。
再调用策略
修改性质的准入插件(包括 Webhook)的任何一种排序方式都不会适用于所有情况。
(参见 https://issue.k8s.io/64333 示例)。
修改性质的 Webhook 可以向对象中添加新的子结构(例如向 pod
中添加 container
),
已经运行的其他修改插件可能会对这些新结构有影响
(就像在所有容器上设置 imagePullPolicy
一样)。
在 v1.15+ 中,允许修改性质的准入插件感应到其他插件所做的更改,
如果修改性质的 Webhook 修改了一个对象,则会重新运行内置的修改性质的准入插件,
并且修改性质的 Webhook 可以指定 reinvocationPolicy
来控制是否也重新调用它们。
可以将 reinvocationPolicy
设置为 Never
或 IfNeeded
。 默认为 Never
。
Never
: 在一次准入测试中,不得多次调用 Webhook。
IfNeeded
: 如果在最初的 Webhook 调用之后被其他对象的插件修改了被接纳的对象,
则可以作为准入测试的一部分再次调用该 webhook。
要注意的重要因素有:
不能保证附加调用的次数恰好是一。
如果其他调用导致对该对象的进一步修改,则不能保证再次调用 Webhook。
使用此选项的 Webhook 可能会重新排序,以最大程度地减少额外调用的次数。
要在确保所有修改都完成后验证对象,请改用验证性质的 Webhook
(推荐用于有副作用的 Webhook)。
这是一个修改性质的 Webhook 的示例,该 Webhook 在以后的准入插件修改对象时被重新调用:
apiVersion : admissionregistration.k8s.io/v1
kind : MutatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
reinvocationPolicy : IfNeeded
...
# v1.16 中被废弃,推荐使用 admissionregistration.k8s.io/v1
apiVersion : admissionregistration.k8s.io/v1beta1
kind : MutatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
reinvocationPolicy : IfNeeded
...
修改性质的 Webhook 必须具有幂等 性,并且能够成功处理
已被接纳并可能被修改的对象的修改性质的 Webhook。
对于所有修改性质的准入 Webhook 都是如此,因为它们可以在对象中进行的
任何更改可能已经存在于用户提供的对象中,但是对于选择重新调用的 webhook
来说是必不可少的。
失败策略
failurePolicy
定义了如何处理准入 webhook 中无法识别的错误和超时错误。允许的值为 Ignore
或 Fail
。
Ignore
表示调用 webhook 的错误将被忽略并且允许 API 请求继续。
Fail
表示调用 webhook 的错误导致准入失败并且 API 请求被拒绝。
这是一个修改性质的 webhook,配置为在调用准入 Webhook 遇到错误时拒绝 API 请求:
apiVersion : admissionregistration.k8s.io/v1
kind : MutatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
failurePolicy : Fail
...
使用 admissionregistration.k8s.io/v1
创建的准入 Webhook 将
failurePolicy
默认设置为 Fail
。
# v1.16 中被废弃,推荐使用 admissionregistration.k8s.io/v1
apiVersion : admissionregistration.k8s.io/v1beta1
kind : MutatingWebhookConfiguration
...
webhooks :
- name : my-webhook.example.com
failurePolicy : Fail
...
使用 admissionregistration.k8s.io/v1beta1
创建的准入 Webhook 将
failurePolicy
默认设置为 Ignore
。
监控 Admission Webhook
API 服务器提供了监视准入 Webhook 行为的方法。这些监视机制可帮助集群管理员
回答以下问题:
哪个修改性质的 webhook 改变了 API 请求中的对象?
修改性质的 Webhook 对对象做了哪些更改?
哪些 webhook 经常拒绝 API 请求?是什么原因拒绝?
Mutating Webhook 审计注解
有时,了解 API 请求中的哪个修改性质的 Webhook 使对象改变以及该
Webhook 应用了哪些更改很有用。
在 v1.16+ 中,kube-apiserver 针对每个修改性质的 Webhook 调用执行
审计 操作。
每个调用都会生成一个审计注解,记述请求对象是否发生改变,
可选地还可以根据 webhook 的准入响应生成一个注解,记述所应用的修补。
针对给定请求的给定执行阶段,注解被添加到审计事件中,
然后根据特定策略进行预处理并写入后端。
事件的审计级别决定了要记录哪些注解:
在 Metadata
或更高审计级别上,将使用 JSON 负载记录带有键名
mutation.webhook.admission.k8s.io/round_{round idx}_index_{order idx}
的注解,
该注解表示针对给定请求调用了 Webhook,以及该 Webhook 是否更改了对象。
例如,对于正在被重新调用的某 Webhook,所记录的注解如下。
Webhook 在 mutating Webhook 链中排在第三个位置,并且在调用期间未改变请求对象。
# 审计事件相关记录
{
"kind": "Event" ,
"apiVersion": "audit.k8s.io/v1" ,
"annotations": {
"mutation.webhook.admission.k8s.io/round_1_index_2": "{\"configuration\":\"my-mutating-webhook-configuration.example.com\",\"webhook\":\"my-webhook.example.com\",\"mutated\": false }"
# 其他注解
...
}
# 其他字段
...
}
# 反序列化的注解值
{
"configuration": "my-mutating-webhook-configuration.example.com" ,
"webhook": "my-webhook.example.com" ,
"mutated": false
}
对于在第一轮中调用的 Webhook,所记录的注解如下。
Webhook 在 mutating Webhook 链中排在第一位,并在调用期间改变了请求对象。
# 审计事件相关记录
{
"kind": "Event" ,
"apiVersion": "audit.k8s.io/v1" ,
"annotations": {
"mutation.webhook.admission.k8s.io/round_0_index_0": "{\"configuration\":\"my-mutating-webhook-configuration.example.com\",\"webhook\":\"my-webhook-always-mutate.example.com\",\"mutated\": true }"
# 其他注解
...
}
# 其他字段
...
}
# 反序列化的注解值
{
"configuration": "my-mutating-webhook-configuration.example.com" ,
"webhook": "my-webhook-always-mutate.example.com" ,
"mutated": true
}
在 Request
或更高审计级别上,将使用 JSON 负载记录带有键名为
patch.webhook.admission.k8s.io/round_{round idx}_index_{order idx}
的注解,
该注解表明针对给定请求调用了 Webhook 以及应用于请求对象之上的修改。
例如,以下是针对正在被重新调用的某 Webhook 所记录的注解。
Webhook 在修改性质的 Webhook 链中排在第四,并在其响应中包含一个 JSON 补丁,
该补丁已被应用于请求对象。
# 审计事件相关记录
{
"kind": "Event" ,
"apiVersion": "audit.k8s.io/v1" ,
"annotations": {
"patch.webhook.admission.k8s.io/round_1_index_3": "{\"configuration\":\"my-other-mutating-webhook-configuration.example.com\",\"webhook\":\"my-webhook-always-mutate.example.com\",\"patch\":[{\"op\":\"add\",\"path\":\"/data/mutation-stage\",\"value\":\"yes\"}],\"patchType\":\"JSONPatch\"}"
# 其他注解
...
}
# 其他字段
...
}
# 反序列化的注解值
{
"configuration": "my-other-mutating-webhook-configuration.example.com" ,
"webhook": "my-webhook-always-mutate.example.com" ,
"patchType": "JSONPatch" ,
"patch": [
{
"op": "add" ,
"path": "/data/mutation-stage" ,
"value": "yes"
}
]
}
准入 Webhook 度量值
Kube-apiserver 从 /metrics
端点公开 Prometheus 指标,这些指标可用于监控和诊断
apiserver 状态。以下指标记录了与准入 Webhook 相关的状态。
apiserver 准入 Webhook 拒绝次数
有时,了解哪些准入 Webhook 经常拒绝 API 请求以及拒绝的原因是很有用的。
在 v1.16+ 中,kube-apiserver 提供了 Prometheus 计数器度量值,记录
准入 Webhook 的拒绝次数。
度量值的标签给出了 Webhook 拒绝该请求的原因:
name
:拒绝请求 Webhook 的名称。
operation
:请求的操作类型可以是 CREATE
、UPDATE
、DELETE
和 CONNECT
其中之一。
type
:Admission webhook 类型,可以是 admit
和 validating
其中之一。
error_type
:标识在 webhook 调用期间是否发生了错误并且导致了拒绝。其值可以是以下之一:
calling_webhook_error
:发生了来自准入 Webhook 的无法识别的错误或超时错误,
并且 webhook 的 失败策略 设置为 Fail
。
no_error
:未发生错误。Webhook 在准入响应中以 allowed: false
值拒绝了请求。
度量标签 rejection_code
记录了在准入响应中设置的 .status.code
。
apiserver_internal_error
:apiserver 发生内部错误。
rejection_code
:当 Webhook 拒绝请求时,在准入响应中设置的 HTTP 状态码。
拒绝计数指标示例:
# HELP apiserver_admission_webhook_rejection_count [ALPHA] Admission webhook rejection count, identified by name and broken out for each admission type (validating or admit) and operation. Additional labels specify an error type (calling_webhook_error or apiserver_internal_error if an error occurred; no_error otherwise) and optionally a non-zero rejection code if the webhook rejects the request with an HTTP status code (honored by the apiserver when the code is greater or equal to 400). Codes greater than 600 are truncated to 600, to keep the metrics cardinality bounded.
# TYPE apiserver_admission_webhook_rejection_count counter
apiserver_admission_webhook_rejection_count{error_type="calling_webhook_error",name="always-timeout-webhook.example.com",operation="CREATE",rejection_code="0",type="validating"} 1
apiserver_admission_webhook_rejection_count{error_type="calling_webhook_error",name="invalid-admission-response-webhook.example.com",operation="CREATE",rejection_code="0",type="validating"} 1
apiserver_admission_webhook_rejection_count{error_type="no_error",name="deny-unwanted-configmap-data.example.com",operation="CREATE",rejection_code="400",type="validating"} 13
最佳实践和警告
幂等性
幂等的修改性质的准入 Webhook 能够成功处理已经被它接纳甚或修改的对象。
即使多次执行该准入测试,也不会产生与初次执行结果相异的结果。
幂等 mutating admission Webhook 的示例:
对于 CREATE
Pod 请求,将 Pod 的字段 .spec.securityContext.runAsNonRoot
设置为 true,以实施安全最佳实践。
对于 CREATE
Pod 请求,如果未设置容器的字段
.spec.containers[].resources.limits
,设置默认资源限制值。
对于 CREATE
pod 请求,如果 Pod 中不存在名为 foo-sidecar
的边车容器,
向 Pod 注入一个 foo-sidecar
容器。
在上述情况下,可以安全地重新调用 Webhook,或接受已经设置了字段的对象。
非幂等 mutating admission Webhook 的示例:
对于 CREATE
pod 请求,注入名称为 foo-sidecar
并带有当前时间戳的
边车容器(例如 foo-sidecar-19700101-000000
)。
对于 CREATE/UPDATE
pod 请求,如果容器已设置标签 "env"
则拒绝,
否则将 "env": "prod"
标签添加到容器。
对于 CREATE
pod 请求,盲目地添加一个名为 foo-sidecar
的边车容器,
而未查看 Pod 中是否已经有 foo-sidecar
容器。
在上述第一种情况下,重新调用该 Webhook 可能导致同一个 Sidecar 容器
多次注入到 Pod 中,而且每次使用不同的容器名称。
类似地,如果 Sidecar 已存在于用户提供的 Pod 中,则 Webhook 可能注入重复的容器。
在上述第二种情况下,重新调用 Webhook 将导致 Webhook 自身输出失败。
在上述第三种情况下,重新调用 Webhook 将导致 Pod 规范中的容器重复,
从而使请求无效并被 API 服务器拒绝。
拦截对象的所有版本
建议通过将 .webhooks[].matchPolicy
设置为 Equivalent
,
以确保准入 Webhooks 始终拦截对象的所有版本。
建议准入 Webhooks 应该更偏向注册资源的稳定版本。
如果无法拦截对象的所有版本,可能会导致准入策略未再某些版本的请求上执行。
有关示例,请参见匹配请求:matchPolicy 。
可用性
建议准入 webhook 尽快完成执行(时长通常是毫秒级),因为它们会增加 API 请求的延迟。
建议对 Webhook 使用较小的超时值。有关更多详细信息,请参见超时 。
建议 Admission Webhook 应该采用某种形式的负载均衡机制,以提供高可用性和高性能。
如果集群中正在运行 Webhook,则可以在服务后面运行多个 Webhook 后端,以利用该服务支持的负载均衡。
确保看到对象的最终状态
如果某准入 Webhook 需要保证自己能够看到对象的最终状态以实施策略,
则应该使用一个验证性质的 webhook,
因为可以通过 mutating Webhook 看到对象后对其进行修改。
例如,一个修改性质的准入Webhook 被配置为在每个 CREATE
Pod 请求中
注入一个名称为 "foo-sidecar" 的 sidecar 容器。
如果必须 存在边车容器,则还应配置一个验证性质的准入 Webhook 以拦截
CREATE
Pod 请求,并验证要创建的对象中是否存在具有预期配置的名称为
"foo-sidecar" 的容器。
避免自托管的 Webhooks 中出现死锁
如果集群内的 Webhook 配置能够拦截启动其自己的 Pod 所需的资源,
则该 Webhook 可能导致其自身部署时发生死锁。
例如,某修改性质的准入 Webhook 配置为仅当 Pod 中设置了某个标签
(例如 "env": "prod"
)时,才接受 CREATE
Pod 请求。
Webhook 服务器在未设置 "env"
标签的 Deployment 中运行。当运行 Webhook 服务器的
容器的节点运行不正常时,Webhook 部署尝试将容器重新调度到另一个节点。
但是,由于未设置 "env"
标签,因此请求将被现有的 Webhook 服务器拒绝,并且调度迁移不会发生。
建议使用 namespaceSelector 排除
Webhook 所在的名字空间。
副作用
建议准入 Webhook 应尽可能避免副作用,这意味着该准入 webhook 仅对发送给他们的
AdmissionReview
的内容起作用,并且不要进行额外更改。
如果 Webhook 没有任何副作用,则 .webhooks[].sideEffects
字段应设置为
None
。
如果在准入执行期间存在副作用,则应在处理 dryRun
为 true
的 AdmissionReview
对象时避免产生副作用,并且其 .webhooks[].sideEffects
字段应设置为
NoneOnDryRun
。更多详细信息,请参见副作用 。
避免对 kube-system 名字空间进行操作
kube-system
名字空间包含由 Kubernetes 系统创建的对象,
例如用于控制平面组件的服务账号,诸如 kube-dns
之类的 Pod 等。
意外更改或拒绝 kube-system
名字空间中的请求可能会导致控制平面组件
停止运行或者导致未知行为发生。
如果你的准入 Webhook 不想修改 Kubernetes 控制平面的行为,请使用
namespaceSelector
避免
拦截 kube-system
名字空间。
3.6 - 管理服务账号
这是一篇针对服务账号的集群管理员指南。你应该熟悉
配置 Kubernetes 服务账号 。
对鉴权和用户账号的支持已在规划中,当前并不完备。
为了更好地描述服务账号,有时这些不完善的特性也会被提及。
用户账号与服务账号
Kubernetes 区分用户账号和服务账号的概念,主要基于以下原因:
用户账号是针对人而言的。 服务账号是针对运行在 Pod 中的进程而言的。
用户账号是全局性的。其名称跨集群中名字空间唯一的。服务账号是名字空间作用域的。
通常情况下,集群的用户账号可能会从企业数据库进行同步,其创建需要特殊权限,
并且涉及到复杂的业务流程。
服务账号创建有意做得更轻量,允许集群用户为了具体的任务创建服务账号
以遵从权限最小化原则。
对人员和服务账号审计所考虑的因素可能不同。
针对复杂系统的配置包可能包含系统组件相关的各种服务账号的定义。因为服务账号
的创建约束不多并且有名字空间域的名称,这种配置是很轻量的。
服务账号的自动化
三个独立组件协作完成服务账号相关的自动化:
ServiceAccount
准入控制器
Token 控制器
ServiceAccount
控制器
ServiceAccount 准入控制器
对 Pod 的改动通过一个被称为
准入控制器
的插件来实现。它是 API 服务器的一部分。
当 Pod 被创建或更新时,它会同步地修改 Pod。
如果该插件处于激活状态(在大多数发行版中都是默认激活的),当 Pod 被创建
或更新时它会进行以下操作:
如果该 Pod 没有设置 ServiceAccount
,将其 ServiceAccount
设为 default
。
保证 Pod 所引用的 ServiceAccount
确实存在,否则拒绝该 Pod。
如果服务账号的 automountServiceAccountToken
或 Pod 的
automountServiceAccountToken
都未显式设置为 false
,则为 Pod 创建一个
volume
,在其中包含用来访问 API 的令牌。
如果前一步中为服务账号令牌创建了卷,则为 Pod 中的每个容器添加一个
volumeSource
,挂载在其 /var/run/secrets/kubernetes.io/serviceaccount
目录下。
如果 Pod 不包含 imagePullSecrets
设置,将 ServiceAccount
所引用
的服务账号中的 imagePullSecrets
信息添加到 Pod 中。
绑定的服务账号令牌卷
FEATURE STATE: Kubernetes v1.22 [stable]
ServiceAccount 准入控制器将添加如下投射卷,而不是为令牌控制器
所生成的不过期的服务账号令牌而创建的基于 Secret 的卷。
- name : kube-api-access-<随机后缀>
projected :
defaultMode : 420 # 0644
sources :
- serviceAccountToken :
expirationSeconds : 3607
path : token
- configMap :
items :
- key : ca.crt
path : ca.crt
name : kube-root-ca.crt
- downwardAPI :
items :
- fieldRef :
apiVersion : v1
fieldPath : metadata.namespace
path : namespace
此投射卷有三个数据源:
通过 TokenRequest API 从 kube-apiserver 处获得的 ServiceAccountToken。
这一令牌默认会在一个小时之后或者 Pod 被删除时过期。
该令牌绑定到 Pod 实例上,并将 kube-apiserver 作为其受众(audience)。
包含用来验证与 kube-apiserver 连接的 CA 证书包的 ConfigMap 对象。
这一特性依赖于 RootCAConfigMap
特性门控。该特性被启用时,
控制面会公开一个名为 kube-root-ca.crt
的 ConfigMap 给所有名字空间。
RootCAConfigMap
在 1.21 版本中进入 GA 状态,默认被启用,
该特性门控会在 1.22 版本中从 --feature-gate
参数中删除。
引用 Pod 名字空间的一个 DownwardAPI。
参阅投射卷
了解进一步的细节。
Token 控制器
TokenController 作为 kube-controller-manager
的一部分运行,以异步的形式工作。
其职责包括:
监测 ServiceAccount 的创建并创建相应的服务账号令牌 Secret 以允许访问 API。
监测 ServiceAccount 的删除并删除所有相应的服务账号令牌 Secret。
监测服务账号令牌 Secret 的添加,保证相应的 ServiceAccount 存在,如有需要,
向 Secret 中添加令牌。
监测服务账号令牌 Secret 的删除,如有需要,从相应的 ServiceAccount 中移除引用。
你必须通过 --service-account-private-key-file
标志为 kube-controller-manager
的令牌控制器传入一个服务账号私钥文件。该私钥用于为所生成的服务账号令牌签名。
同样地,你需要通过 --service-account-key-file
标志将对应的公钥通知给
kube-apiserver。公钥用于在身份认证过程中校验令牌。
创建额外的 API 令牌
控制器中有专门的循环来保证每个 ServiceAccount 都存在对应的包含 API 令牌的 Secret。
当需要为 ServiceAccount 创建额外的 API 令牌时,可以创建一个类型为
kubernetes.io/service-account-token
的 Secret,并在其注解中引用对应的
ServiceAccount。控制器会生成令牌并更新该 Secret:
下面是这种 Secret 的一个示例配置:
apiVersion : v1
kind : Secret
metadata :
name : mysecretname
annotations :
kubernetes.io/service-account.name : myserviceaccount
type : kubernetes.io/service-account-token
kubectl create -f ./secret.json
kubectl describe secret mysecretname
删除/废止服务账号令牌 Secret
kubectl delete secret mysecretname
服务账号控制器
服务账号控制器管理各名字空间下的 ServiceAccount 对象,并且保证每个活跃的
名字空间下存在一个名为 "default" 的 ServiceAccount。
3.7 - 鉴权概述
了解有关 Kubernetes 鉴权的更多信息,包括使用支持的鉴权模块创建策略的详细信息。
在 Kubernetes 中,你必须在鉴权(授予访问权限)之前进行身份验证(登录),有关身份验证的信息,
请参阅访问控制概述 .
Kubernetes 期望请求中存在 REST API 常见的属性。
这意味着 Kubernetes 鉴权适用于现有的组织范围或云提供商范围的访问控制系统,
除了 Kubernetes API 之外,它还可以处理其他 API。
确定是允许还是拒绝请求
Kubernetes 使用 API 服务器对 API 请求进行鉴权。
它根据所有策略评估所有请求属性来决定允许或拒绝请求。
一个 API 请求的所有部分都必须被某些策略允许才能继续。
这意味着默认情况下拒绝权限。
(尽管 Kubernetes 使用 API 服务器,但是依赖于特定对象种类的特定字段的访问控制
和策略由准入控制器处理。)
当系统配置了多个鉴权模块时,Kubernetes 将按顺序使用每个模块。
如果任何鉴权模块批准或拒绝请求,则立即返回该决定,并且不会与其他鉴权模块协商。
如果所有模块对请求没有意见,则拒绝该请求。
被拒绝响应返回 HTTP 状态代码 403。
审查你的请求属性
Kubernetes 仅审查以下 API 请求属性:
用户 - 身份验证期间提供的 user
字符串。
组 - 经过身份验证的用户所属的组名列表。
额外信息 - 由身份验证层提供的任意字符串键到字符串值的映射。
API - 指示请求是否针对 API 资源。
请求路径 - 各种非资源端点的路径,如 /api
或 /healthz
。
API 请求动词 - API 动词 get
、list
、create
、update
、patch
、watch
、
proxy
、redirect
、delete
和 deletecollection
用于资源请求。
要确定资源 API 端点的请求动词,请参阅
确定请求动词 。
HTTP 请求动词 - HTTP 动词 get
、post
、put
和 delete
用于非资源请求。
Resource - 正在访问的资源的 ID 或名称(仅限资源请求)-
对于使用 get
、update
、patch
和 delete
动词的资源请求,你必须提供资源名称。
子资源 - 正在访问的子资源(仅限资源请求)。
名字空间 - 正在访问的对象的名称空间(仅适用于名字空间资源请求)。
API 组 - 正在访问的 API 组
(仅限资源请求)。空字符串表示核心 API 组 。
确定请求动词
非资源请求
对于 /api/v1/...
或 /apis/<group>/<version>/...
之外的端点的请求被
视为“非资源请求(Non-Resource Requests)”,并使用该请求的 HTTP 方法的
小写形式作为其请求动词。
例如,对 /api
或 /healthz
这类端点的 GET
请求将使用 get
作为其动词。
资源请求
要确定对资源 API 端点的请求动词,需要查看所使用的 HTTP 动词以及该请求是针对
单个资源还是一组资源:
HTTP 动词
请求动词
POST
create
GET, HEAD
get (针对单个资源)、list(针对集合)
PUT
update
PATCH
patch
DELETE
delete(针对单个资源)、deletecollection(针对集合)
Kubernetes 有时使用专门的动词以对额外的权限进行鉴权。例如:
PodSecurityPolicy
policy
API 组中 podsecuritypolicies
资源使用 use
动词
RBAC
对 rbac.authorization.k8s.io
API 组中 roles
和 clusterroles
资源的 bind
和 escalate
动词
身份认证
对核心 API 组中 users
、groups
和 serviceaccounts
以及 authentication.k8s.io
API 组中的 userextras
所使用的 impersonate
动词。
鉴权模块
Node - 一个专用鉴权组件,根据调度到 kubelet 上运行的 Pod 为 kubelet 授予权限。
了解有关使用节点鉴权模式的更多信息,请参阅节点鉴权 。
ABAC - 基于属性的访问控制(ABAC)定义了一种访问控制范型,通过使用将属性组合
在一起的策略,将访问权限授予用户。策略可以使用任何类型的属性(用户属性、资源属性、
对象,环境属性等)。要了解有关使用 ABAC 模式的更多信息,请参阅
ABAC 模式 。
RBAC - 基于角色的访问控制(RBAC)是一种基于企业内个人用户的角色来管理对
计算机或网络资源的访问的方法。在此上下文中,权限是单个用户执行特定任务的能力,
例如查看、创建或修改文件。要了解有关使用 RBAC 模式的更多信息,请参阅
RBAC 模式 。
被启用之后,RBAC(基于角色的访问控制)使用 rbac.authorization.k8s.io
API 组来
驱动鉴权决策,从而允许管理员通过 Kubernetes API 动态配置权限策略。
要启用 RBAC,请使用 --authorization-mode = RBAC
启动 API 服务器。
Webhook - WebHook 是一个 HTTP 回调:发生某些事情时调用的 HTTP POST;
通过 HTTP POST 进行简单的事件通知。实现 WebHook 的 Web 应用程序会在发生某些事情时
将消息发布到 URL。要了解有关使用 Webhook 模式的更多信息,请参阅
Webhook 模式 。
检查 API 访问
kubectl
提供 auth can-i
子命令,用于快速查询 API 鉴权。
该命令使用 SelfSubjectAccessReview
API 来确定当前用户是否可以执行给定操作,
无论使用何种鉴权模式该命令都可以工作。
kubectl auth can-i create deployments --namespace dev
输出类似于:
yes
kubectl auth can-i create deployments --namespace prod
输出类似于:
no
管理员可以将此与
用户扮演
结合使用,以确定其他用户可以执行的操作。
kubectl auth can-i list secrets --namespace dev --as dave
输出类似于:
no
类似地,检查名字空间 dev
里的 dev-sa
服务账号是否可以列举名字空间 target
里的 Pod:
kubectl auth can-i list pods \
--namespace target \
--as system:serviceaccount:dev:dev-sa
输出类似于:
yes
SelfSubjectAccessReview
是 authorization.k8s.io
API 组的一部分,它将 API
服务器鉴权公开给外部服务。该组中的其他资源包括:
SubjectAccessReview
- 对任意用户的访问进行评估,而不仅仅是当前用户。
当鉴权决策被委派给 API 服务器时很有用。例如,kubelet 和扩展 API 服务器使用
它来确定用户对自己的 API 的访问权限。
LocalSubjectAccessReview
- 与 SubjectAccessReview
类似,但仅限于特定的
名字空间。
SelfSubjectRulesReview
- 返回用户可在名字空间内执行的操作集的审阅。
用户可以快速汇总自己的访问权限,或者用于 UI 中的隐藏/显示动作。
可以通过创建普通的 Kubernetes 资源来查询这些 API,其中返回对象的响应 "status"
字段是查询的结果。
kubectl create -f - -o yaml << EOF
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
resourceAttributes:
group: apps
name: deployments
verb: create
namespace: dev
EOF
生成的 SelfSubjectAccessReview
为:
apiVersion : authorization.k8s.io/v1
kind : SelfSubjectAccessReview
metadata :
creationTimestamp : null
spec :
resourceAttributes :
group : apps
name : deployments
namespace : dev
verb : create
status :
allowed : true
denied : false
为你的鉴权模块设置参数
你必须在策略中包含一个参数标志,以指明你的策略包含哪个鉴权模块:
可以使用的参数有:
--authorization-mode=ABAC
基于属性的访问控制(ABAC)模式允许你
使用本地文件配置策略。
--authorization-mode=RBAC
基于角色的访问控制(RBAC)模式允许你使用
Kubernetes API 创建和存储策略。
--authorization-mode=Webhook
WebHook 是一种 HTTP 回调模式,允许你使用远程
REST 端点管理鉴权。
--authorization-mode=Node
节点鉴权是一种特殊用途的鉴权模式,专门对
kubelet 发出的 API 请求执行鉴权。
--authorization-mode=AlwaysDeny
该标志阻止所有请求。仅将此标志用于测试。
--authorization-mode=AlwaysAllow
此标志允许所有请求。仅在你不需要 API 请求
的鉴权时才使用此标志。
你可以选择多个鉴权模块。模块按顺序检查,以便较靠前的模块具有更高的优先级来允许
或拒绝请求。
通过创建或编辑工作负载提升权限
能够在名字空间中创建或者编辑 Pod 的用户,
无论是直接操作还是通过控制器 (例如,一个 Operator)来操作,
都可以提升他们在该名字空间内的权限。
注意:
系统管理员在授予对工作负载的创建或编辑的权限时要小心。
关于这些权限如何被误用的详细信息请参阅
提升途径
提升途径
挂载该名字空间内的任意 Secret
可以用来访问其他工作负载专用的 Secret
可以用来获取权限更高的服务账号的令牌
使用该名字空间内的任意服务账号
可以用另一个工作负载的身份来访问 Kubernetes API(伪装)
可以执行该服务账号的任意特权操作
挂载该名字空间里其他工作负载专用的 ConfigMap
可以用来获取其他工作负载专用的信息,例如数据库主机名。
挂载该名字空间里其他工作负载的卷
注意:
系统管理员在部署改变以上部分的 CRD 的时候要小心。
它们可能会打开权限提升的途径。
在决定你的 RBAC 控制时应该考虑这方面的问题。
接下来
3.8 - 使用 RBAC 鉴权
基于角色(Role)的访问控制(RBAC)是一种基于组织中用户的角色来调节控制对
计算机或网络资源的访问的方法。
RBAC 鉴权机制使用 rbac.authorization.k8s.io
API 组
来驱动鉴权决定,允许你通过 Kubernetes API 动态配置策略。
要启用 RBAC,在启动 API 服务器
时将 --authorization-mode
参数设置为一个逗号分隔的列表并确保其中包含 RBAC
。
kube-apiserver --authorization-mode= Example,RBAC --<其他选项> --<其他选项>
API 对象
RBAC API 声明了四种 Kubernetes 对象:Role 、ClusterRole 、RoleBinding 和
ClusterRoleBinding 。你可以像使用其他 Kubernetes 对象一样,
通过类似 kubectl
这类工具
描述对象 ,
或修补对象。
注意:
这些对象在设计时即实施了一些访问限制。如果你在学习过程中对集群做了更改,请参考
避免特权提升和引导
一节,以了解这些限制会以怎样的方式阻止你做出修改。
Role 和 ClusterRole
RBAC 的 Role 或 ClusterRole 中包含一组代表相关权限的规则。
这些权限是纯粹累加的(不存在拒绝某操作的规则)。
Role 总是用来在某个名字空间
内设置访问权限;在你创建 Role 时,你必须指定该 Role 所属的名字空间。
与之相对,ClusterRole 则是一个集群作用域的资源。这两种资源的名字不同(Role 和
ClusterRole)是因为 Kubernetes 对象要么是名字空间作用域的,要么是集群作用域的,
不可两者兼具。
ClusterRole 有若干用法。你可以用它来:
定义对某名字空间域对象的访问权限,并将在各个名字空间内完成授权;
为名字空间作用域的对象设置访问权限,并跨所有名字空间执行授权;
为集群作用域的资源定义访问权限。
如果你希望在名字空间内定义角色,应该使用 Role;
如果你希望定义集群范围的角色,应该使用 ClusterRole。
Role 示例
下面是一个位于 "default" 名字空间的 Role 的示例,可用来授予对
pods 的读访问权限:
apiVersion : rbac.authorization.k8s.io/v1
kind : Role
metadata :
namespace : default
name : pod-reader
rules :
- apiGroups : ["" ] # "" 标明 core API 组
resources : ["pods" ]
verbs : ["get" , "watch" , "list" ]
ClusterRole 示例
ClusterRole 可以和 Role 相同完成授权。
因为 ClusterRole 属于集群范围,所以它也可以为以下资源授予访问权限:
下面是一个 ClusterRole 的示例,可用来为任一特定名字空间中的
Secret 授予读访问权限,
或者跨名字空间的访问权限(取决于该角色是如何绑定 的):
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRole
metadata :
# "namespace" 被忽略,因为 ClusterRoles 不受名字空间限制
name : secret-reader
rules :
- apiGroups : ["" ]
# 在 HTTP 层面,用来访问 Secret 对象的资源的名称为 "secrets"
resources : ["secrets" ]
verbs : ["get" , "watch" , "list" ]
Role 或 ClusterRole 对象的名称必须是合法的
路径区段名称 。
RoleBinding 和 ClusterRoleBinding
角色绑定(Role Binding)是将角色中定义的权限赋予一个或者一组用户。
它包含若干 主体 (用户、组或服务账户)的列表和对这些主体所获得的角色的引用。
RoleBinding 在指定的名字空间中执行授权,而 ClusterRoleBinding 在集群范围执行授权。
一个 RoleBinding 可以引用同一的名字空间中的任何 Role。
或者,一个 RoleBinding 可以引用某 ClusterRole 并将该 ClusterRole 绑定到
RoleBinding 所在的名字空间。
如果你希望将某 ClusterRole 绑定到集群中所有名字空间,你要使用 ClusterRoleBinding。
RoleBinding 或 ClusterRoleBinding 对象的名称必须是合法的
路径区段名称 。
RoleBinding 示例
下面的例子中的 RoleBinding 将 "pod-reader" Role 授予在 "default" 名字空间中的用户 "jane"。
这样,用户 "jane" 就具有了读取 "default" 名字空间中 pods 的权限。
apiVersion : rbac.authorization.k8s.io/v1
# 此角色绑定允许 "jane" 读取 "default" 名字空间中的 Pods
kind : RoleBinding
metadata :
name : read-pods
namespace : default
subjects :
# 你可以指定不止一个“subject(主体)”
- kind : User
name : jane # "name" 是区分大小写的
apiGroup : rbac.authorization.k8s.io
roleRef :
# "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系
kind : Role # 此字段必须是 Role 或 ClusterRole
name : pod-reader # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配
apiGroup : rbac.authorization.k8s.io
RoleBinding 也可以引用 ClusterRole,以将对应 ClusterRole 中定义的访问权限授予
RoleBinding 所在名字空间的资源。这种引用使得你可以跨整个集群定义一组通用的角色,
之后在多个名字空间中复用。
例如,尽管下面的 RoleBinding 引用的是一个 ClusterRole,"dave"(这里的主体,
区分大小写)只能访问 "development" 名字空间中的 Secrets 对象,因为 RoleBinding
所在的名字空间(由其 metadata 决定)是 "development"。
apiVersion : rbac.authorization.k8s.io/v1
# 此角色绑定使得用户 "dave" 能够读取 "development" 名字空间中的 Secrets
# 你需要一个名为 "secret-reader" 的 ClusterRole
kind : RoleBinding
metadata :
name : read-secrets
# RoleBinding 的名字空间决定了访问权限的授予范围。
# 这里隐含授权仅在 "development" 名字空间内的访问权限。
namespace : development
subjects :
- kind : User
name : dave # 'name' 是区分大小写的
apiGroup : rbac.authorization.k8s.io
roleRef :
kind : ClusterRole
name : secret-reader
apiGroup : rbac.authorization.k8s.io
ClusterRoleBinding 示例
要跨整个集群完成访问权限的授予,你可以使用一个 ClusterRoleBinding。
下面的 ClusterRoleBinding 允许 "manager" 组内的所有用户访问任何名字空间中的
Secrets。
apiVersion : rbac.authorization.k8s.io/v1
# 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 secrets
kind : ClusterRoleBinding
metadata :
name : read-secrets-global
subjects :
- kind : Group
name : manager # 'name' 是区分大小写的
apiGroup : rbac.authorization.k8s.io
roleRef :
kind : ClusterRole
name : secret-reader
apiGroup : rbac.authorization.k8s.io
创建了绑定之后,你不能再修改绑定对象所引用的 Role 或 ClusterRole。
试图改变绑定对象的 roleRef
将导致合法性检查错误。
如果你想要改变现有绑定对象中 roleRef
字段的内容,必须删除重新创建绑定对象。
这种限制有两个主要原因:
针对不同角色的绑定是完全不一样的绑定。要求通过删除/重建绑定来更改 roleRef
,
这样可以确保要赋予绑定的所有主体会被授予新的角色(而不是在允许或者不小心修改
了 roleRef
的情况下导致所有现有主体未经验证即被授予新角色对应的权限)。
将 roleRef
设置为不可以改变,这使得可以为用户授予对现有绑定对象的 update
权限,
这样可以让他们管理主体列表,同时不能更改被授予这些主体的角色。
命令 kubectl auth reconcile
可以创建或者更新包含 RBAC 对象的清单文件,
并且在必要的情况下删除和重新创建绑定对象,以改变所引用的角色。
更多相关信息请参照命令用法和示例
对资源的引用
在 Kubernetes API 中,大多数资源都是使用对象名称的字符串表示来呈现与访问的。
例如,对于 Pod 应使用 "pods"。
RBAC 使用对应 API 端点的 URL 中呈现的名字来引用资源。
有一些 Kubernetes API 涉及 子资源(subresource) ,例如 Pod 的日志。
对 Pod 日志的请求看起来像这样:
GET /api/v1/namespaces/{namespace}/pods/{name}/log
在这里,pods
对应名字空间作用域的 Pod 资源,而 log
是 pods
的子资源。
在 RBAC 角色表达子资源时,使用斜线(/
)来分隔资源和子资源。
要允许某主体读取 pods
同时访问这些 Pod 的 log
子资源,你可以这么写:
apiVersion : rbac.authorization.k8s.io/v1
kind : Role
metadata :
namespace : default
name : pod-and-pod-logs-reader
rules :
- apiGroups : ["" ]
resources : ["pods" , "pods/log" ]
verbs : ["get" , "list" ]
对于某些请求,也可以通过 resourceNames
列表按名称引用资源。
在指定时,可以将请求限定为资源的单个实例。
下面的例子中限制可以 "get" 和 "update" 一个名为 my-configmap
的
ConfigMap :
apiVersion : rbac.authorization.k8s.io/v1
kind : Role
metadata :
namespace : default
name : configmap-updater
rules :
- apiGroups : ["" ]
# 在 HTTP 层面,用来访问 ConfigMap 的资源的名称为 "configmaps"
resources : ["configmaps" ]
resourceNames : ["my-configmap" ]
verbs : ["update" , "get" ]
说明:
你不能使用资源名字来限制 create
或者 deletecollection
请求。
对于 create
请求而言,这是因为在鉴权时可能还不知道新对象的名字。
如果你使用 resourceName 来限制 list
或者 watch
请求,
客户端必须在它们的 list
或者 watch
请求里包含一个与指定的 resourceName 匹配的 metadata.name
字段选择器。
例如,kubectl get configmaps --field-selector=metadata.name=my-configmap
聚合的 ClusterRole
你可以将若干 ClusterRole 聚合(Aggregate) 起来,形成一个复合的 ClusterRole。
某个控制器作为集群控制面的一部分会监视带有 aggregationRule
的 ClusterRole
对象集合。aggregationRule
为控制器定义一个标签
选择算符 供后者匹配
应该组合到当前 ClusterRole 的 roles
字段中的 ClusterRole 对象。
下面是一个聚合 ClusterRole 的示例:
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRole
metadata :
name : monitoring
aggregationRule :
clusterRoleSelectors :
- matchLabels :
rbac.example.com/aggregate-to-monitoring : "true"
rules : [] # 控制面自动填充这里的规则
如果你创建一个与某个已存在的聚合 ClusterRole 的标签选择算符匹配的 ClusterRole,
这一变化会触发新的规则被添加到聚合 ClusterRole 的操作。
下面的例子中,通过创建一个标签同样为 rbac.example.com/aggregate-to-monitoring: true
的 ClusterRole,新的规则可被添加到 "monitoring" ClusterRole 中。
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRole
metadata :
name : monitoring-endpoints
labels :
rbac.example.com/aggregate-to-monitoring : "true"
# 当你创建 "monitoring-endpoints" ClusterRole 时,
# 下面的规则会被添加到 "monitoring" ClusterRole 中
rules :
- apiGroups : ["" ]
resources : ["services" , "endpoints" , "pods" ]
verbs : ["get" , "list" , "watch" ]
默认的面向用户的角色 使用 ClusterRole 聚合。
这使得作为集群管理员的你可以为扩展默认规则,包括为定制资源设置规则,
比如通过 CustomResourceDefinitions 或聚合 API 服务器提供的定制资源。
例如,下面的 ClusterRoles 让默认角色 "admin" 和 "edit" 拥有管理自定义资源 "CronTabs" 的权限,
"view" 角色对 CronTab 资源拥有读操作权限。
你可以假定 CronTab 对象在 API 服务器所看到的 URL 中被命名为 "crontabs"
。
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRole
metadata :
name : aggregate-cron-tabs-edit
labels :
# 添加以下权限到默认角色 "admin" 和 "edit" 中
rbac.authorization.k8s.io/aggregate-to-admin : "true"
rbac.authorization.k8s.io/aggregate-to-edit : "true"
rules :
- apiGroups : ["stable.example.com" ]
resources : ["crontabs" ]
verbs : ["get" , "list" , "watch" , "create" , "update" , "patch" , "delete" ]
---
kind : ClusterRole
apiVersion : rbac.authorization.k8s.io/v1
metadata :
name : aggregate-cron-tabs-view
labels :
# 添加以下权限到 "view" 默认角色中
rbac.authorization.k8s.io/aggregate-to-view : "true"
rules :
- apiGroups : ["stable.example.com" ]
resources : ["crontabs" ]
verbs : ["get" , "list" , "watch" ]
Role 示例
以下示例均为从 Role 或 ClusterRole 对象中截取出来,我们仅展示其 rules
部分。
允许读取在核心 API 组 下的
"Pods"
:
rules :
- apiGroups : ["" ]
# 在 HTTP 层面,用来访问 Pod 的资源的名称为 "pods"
resources : ["pods" ]
verbs : ["get" , "list" , "watch" ]
允许读/写在 "extensions" 和 "apps" API 组中的 Deployment(在 HTTP 层面,对应
URL 中资源部分为 "deployments"):
rules :
- apiGroups : ["extensions" , "apps" ]
resources : ["deployments" ]
verbs : ["get" , "list" , "watch" , "create" , "update" , "patch" , "delete" ]
允许读取核心 API 组中的 "pods" 和读/写 "batch"
或 "extensions"
API 组中的
"jobs":
rules :
- apiGroups : ["" ]
resources : ["pods" ]
verbs : ["get" , "list" , "watch" ]
- apiGroups : ["batch" , "extensions" ]
resources : ["jobs" ]
verbs : ["get" , "list" , "watch" , "create" , "update" , "patch" , "delete" ]
允许读取名称为 "my-config" 的 ConfigMap(需要通过 RoleBinding 绑定以
限制为某名字空间中特定的 ConfigMap):
rules :
- apiGroups : ["" ]
resources : ["configmaps" ]
resourceNames : ["my-config" ]
verbs : ["get" ]
允许读取在核心组中的 "nodes" 资源(因为 Node
是集群作用域的,所以需要
ClusterRole 绑定到 ClusterRoleBinding 才生效):
rules :
- apiGroups : ["" ]
resources : ["nodes" ]
verbs : ["get" , "list" , "watch" ]
允许针对非资源端点 /healthz
和其子路径上发起 GET 和 POST 请求
(必须在 ClusterRole 绑定 ClusterRoleBinding 才生效):
rules :
- nonResourceURLs : ["/healthz" , "/healthz/*" ] # nonResourceURL 中的 '*' 是一个全局通配符
verbs : ["get" , "post" ]
对主体的引用
RoleBinding 或者 ClusterRoleBinding 可绑定角色到某 *主体(Subject)*上。
主体可以是组,用户或者
服务账户 。
Kubernetes 用字符串来表示用户名。
用户名可以是普通的用户名,像 "alice";或者是邮件风格的名称,如 "bob@example.com",
或者是以字符串形式表达的数字 ID。
你作为 Kubernetes 管理员负责配置
身份认证模块
以便后者能够生成你所期望的格式的用户名。
注意:
前缀 system:
是 Kubernetes 系统保留的,所以你要确保
所配置的用户名或者组名不能出现上述 system:
前缀。
除了对前缀的限制之外,RBAC 鉴权系统不对用户名格式作任何要求。
在 Kubernetes 中,鉴权模块提供用户组信息。
与用户名一样,用户组名也用字符串来表示,而且对该字符串没有格式要求,
只是不能使用保留的前缀 system:
。
服务账户
的用户名前缀为 system:serviceaccount:
,属于前缀为 system:serviceaccounts:
的用户组。
说明:
system:serviceaccount:
(单数)是用于服务账户用户名的前缀;
system:serviceaccounts:
(复数)是用于服务账户组名的前缀。
RoleBinding 示例
下面示例是 RoleBinding
中的片段,仅展示其 subjects
的部分。
对于名称为 alice@example.com
的用户:
subjects :
- kind : User
name : "alice@example.com"
apiGroup : rbac.authorization.k8s.io
对于名称为 frontend-admins
的用户组:
subjects :
- kind : Group
name : "frontend-admins"
apiGroup : rbac.authorization.k8s.io
对于 kube-system
名字空间中的默认服务账户:
subjects :
- kind : ServiceAccount
name : default
namespace : kube-system
对于任何名称空间中的 "qa" 组中所有的服务账户:
subjects :
- kind : Group
name : system:serviceaccounts:qa
apiGroup : rbac.authorization.k8s.io
对于 "development" 名称空间中 "dev" 组中的所有服务帐户:
subjects :
- kind : Group
name : system:serviceaccounts:dev
apiGroup : rbac.authorization.k8s.io
namespace : development
对于在任何名字空间中的服务账户:
subjects :
- kind : Group
name : system:serviceaccounts
apiGroup : rbac.authorization.k8s.io
对于所有已经过认证的用户:
subjects :
- kind : Group
name : system:authenticated
apiGroup : rbac.authorization.k8s.io
对于所有未通过认证的用户:
subjects :
- kind : Group
name : system:unauthenticated
apiGroup : rbac.authorization.k8s.io
对于所有用户:
subjects :
- kind : Group
name : system:authenticated
apiGroup : rbac.authorization.k8s.io
- kind : Group
name : system:unauthenticated
apiGroup : rbac.authorization.k8s.io
默认 Roles 和 Role Bindings
API 服务器创建一组默认的 ClusterRole 和 ClusterRoleBinding 对象。
这其中许多是以 system:
为前缀的,用以标识对应资源是直接由集群控制面管理的。
所有的默认 ClusterRole 和 ClusterRoleBinding 都有
kubernetes.io/bootstrapping=rbac-defaults
标签。
注意:
在修改名称包含 system:
前缀的 ClusterRole 和 ClusterRoleBinding
时要格外小心。
对这些资源的更改可能导致集群无法继续工作。
自动协商
在每次启动时,API 服务器都会更新默认 ClusterRole 以添加缺失的各种权限,并更新
默认的 ClusterRoleBinding 以增加缺失的各类主体。
这种自动协商机制允许集群去修复一些不小心发生的修改,并且有助于保证角色和角色绑定
在新的发行版本中有权限或主体变更时仍然保持最新。
如果要禁止此功能,请将默认 ClusterRole 以及 ClusterRoleBinding 的
rbac.authorization.kubernetes.io/autoupdate
注解设置成 false
。
注意,缺少默认权限和角色绑定主体可能会导致集群无法正常工作。
如果基于 RBAC 的鉴权机制被启用,则自动协商功能默认是被启用的。
API 发现角色
无论是经过身份验证的还是未经过身份验证的用户,默认的角色绑定都授权他们读取被认为
是可安全地公开访问的 API( 包括 CustomResourceDefinitions)。
如果要禁用匿名的未经过身份验证的用户访问,请在 API 服务器配置中中添加
--anonymous-auth=false
的配置选项。
通过运行命令 kubectl
可以查看这些角色的配置信息:
kubectl get clusterroles system:discovery -o yaml
说明:
如果你编辑该 ClusterRole,你所作的变更会被 API 服务器在重启时自动覆盖,这是通过
自动协商 机制完成的。要避免这类覆盖操作,
要么不要手动编辑这些角色,要么禁止自动协商机制。
Kubernetes RBAC API 发现角色
默认 ClusterRole
默认 ClusterRoleBinding
描述
system:basic-user
system:authenticated 组
允许用户以只读的方式去访问他们自己的基本信息。在 1.14 版本之前,这个角色在默认情况下也绑定在 system:unauthenticated 上。
system:discovery
system:authenticated 组
允许以只读方式访问 API 发现端点,这些端点用来发现和协商 API 级别。
在 1.14 版本之前,这个角色在默认情况下绑定在 system:unauthenticated 上。
system:public-info-viewer
system:authenticated 和 system:unauthenticated 组
允许对集群的非敏感信息进行只读访问,它是在 1.14 版本中引入的。
面向用户的角色
一些默认的 ClusterRole 不是以前缀 system:
开头的。这些是面向用户的角色。
它们包括超级用户(Super-User)角色(cluster-admin
)、
使用 ClusterRoleBinding 在集群范围内完成授权的角色(cluster-status
)、
以及使用 RoleBinding 在特定名字空间中授予的角色(admin
、edit
、view
)。
面向用户的 ClusterRole 使用 ClusterRole 聚合 以允许管理员在
这些 ClusterRole 上添加用于定制资源的规则。如果想要添加规则到 admin
、edit
或者 view
,
可以创建带有以下一个或多个标签的 ClusterRole:
metadata :
labels :
rbac.authorization.k8s.io/aggregate-to-admin : "true"
rbac.authorization.k8s.io/aggregate-to-edit : "true"
rbac.authorization.k8s.io/aggregate-to-view : "true"
默认 ClusterRole
默认 ClusterRoleBinding
描述
cluster-admin
system:masters 组
允许超级用户在平台上的任何资源上执行所有操作。
当在 ClusterRoleBinding 中使用时,可以授权对集群中以及所有名字空间中的全部资源进行完全控制。
当在 RoleBinding 中使用时,可以授权控制 RoleBinding 所在名字空间中的所有资源,包括名字空间本身。
admin
无
允许管理员访问权限,旨在使用 RoleBinding 在名字空间内执行授权。
如果在 RoleBinding 中使用,则可授予对名字空间中的大多数资源的读/写权限,
包括创建角色和角色绑定的能力。
此角色不允许对资源配额或者名字空间本身进行写操作。
此角色也不允许对 Kubernetes v1.22+ 创建的 Endpoints 进行写操作。
更多信息参阅“Endpoints 写权限”小节 。
edit
无
允许对名字空间的大多数对象进行读/写操作。
它不允许查看或者修改角色或者角色绑定。
不过,此角色可以访问 Secret,以名字空间中任何 ServiceAccount 的身份运行 Pods,
所以可以用来了解名字空间内所有服务账户的 API 访问级别。
此角色也不允许对 Kubernetes v1.22+ 创建的 Endpoints 进行写操作。
更多信息参阅“Endpoints 写操作”小节 。
view
无
允许对名字空间的大多数对象有只读权限。
它不允许查看角色或角色绑定。
此角色不允许查看 Secrets,因为读取 Secret 的内容意味着可以访问名字空间中
ServiceAccount 的凭据信息,进而允许利用名字空间中任何 ServiceAccount 的
身份访问 API(这是一种特权提升)。
核心组件角色
默认 ClusterRole
默认 ClusterRoleBinding
描述
system:kube-scheduler
system:kube-scheduler 用户
允许访问 scheduler
组件所需要的资源。
system:volume-scheduler
system:kube-scheduler 用户
允许访问 kube-scheduler 组件所需要的卷资源。
system:kube-controller-manager
system:kube-controller-manager 用户
允许访问控制器管理器
组件所需要的资源。
各个控制回路所需要的权限在控制器角色 详述。
system:node
无
允许访问 kubelet 所需要的资源,包括对所有 Secret 的读操作和对所有 Pod 状态对象的写操作。
你应该使用 Node 鉴权组件 和
NodeRestriction 准入插件
而不是 system:node 角色。同时基于 kubelet 上调度执行的 Pod 来授权
kubelet 对 API 的访问。
system:node 角色的意义仅是为了与从 v1.8 之前版本升级而来的集群兼容。
system:node-proxier
system:kube-proxy 用户
允许访问 kube-proxy
组件所需要的资源。
其他组件角色
默认 ClusterRole
默认 ClusterRoleBinding
描述
system:auth-delegator
无
允许将身份认证和鉴权检查操作外包出去。
这种角色通常用在插件式 API 服务器上,以实现统一的身份认证和鉴权。
system:heapster
无
为 Heapster 组件(已弃用)定义的角色。
system:kube-aggregator
无
为 kube-aggregator 组件定义的角色。
system:kube-dns
在 kube-system 名字空间中的 kube-dns 服务账户
为 kube-dns 组件定义的角色。
system:kubelet-api-admin
无
允许 kubelet API 的完全访问权限。
system:node-bootstrapper
无
允许访问执行
kubelet TLS 启动引导
所需要的资源。
system:node-problem-detector
无
为 node-problem-detector 组件定义的角色。
system:persistent-volume-provisioner
无
允许访问大部分
动态卷驱动
所需要的资源。
system:monitoring
system:monitoring 组
允许对控制平面监控端点的读取访问(例如:kube-apiserver
存活和就绪端点(/healthz 、/livez 、/readyz ),
各个健康检查端点(/healthz/* 、/livez/* 、/readyz/* )和 /metrics )。
请注意,各个运行状况检查端点和度量标准端点可能会公开敏感信息。
内置控制器的角色
Kubernetes 控制器管理器
运行内建于 Kubernetes 控制面的控制器 。
当使用 --use-service-account-credentials
参数启动时, kube-controller-manager
使用单独的服务账户来启动每个控制器。
每个内置控制器都有相应的、前缀为 system:controller:
的角色。
如果控制管理器启动时未设置 --use-service-account-credentials
,
它使用自己的身份凭据来运行所有的控制器,该身份必须被授予所有相关的角色。
这些角色包括:
system:controller:attachdetach-controller
system:controller:certificate-controller
system:controller:clusterrole-aggregation-controller
system:controller:cronjob-controller
system:controller:daemon-set-controller
system:controller:deployment-controller
system:controller:disruption-controller
system:controller:endpoint-controller
system:controller:expand-controller
system:controller:generic-garbage-collector
system:controller:horizontal-pod-autoscaler
system:controller:job-controller
system:controller:namespace-controller
system:controller:node-controller
system:controller:persistent-volume-binder
system:controller:pod-garbage-collector
system:controller:pv-protection-controller
system:controller:pvc-protection-controller
system:controller:replicaset-controller
system:controller:replication-controller
system:controller:resourcequota-controller
system:controller:root-ca-cert-publisher
system:controller:route-controller
system:controller:service-account-controller
system:controller:service-controller
system:controller:statefulset-controller
system:controller:ttl-controller
初始化与预防权限提升
RBAC API 会阻止用户通过编辑角色或者角色绑定来提升权限。
由于这一点是在 API 级别实现的,所以在 RBAC 鉴权组件未启用的状态下依然可以正常工作。
对角色创建或更新的限制
只有在符合下列条件之一的情况下,你才能创建/更新角色:
你已经拥有角色中包含的所有权限,且其作用域与正被修改的对象作用域相同。
(对 ClusterRole 而言意味着集群范围,对 Role 而言意味着相同名字空间或者集群范围)。
你被显式授权在 rbac.authorization.k8s.io
API 组中的 roles
或 clusterroles
资源
使用 escalate
动词。
例如,如果 user-1
没有列举集群范围所有 Secret 的权限,他将不能创建包含该权限的 ClusterRole。
若要允许用户创建/更新角色:
根据需要赋予他们一个角色,允许他们根据需要创建/更新 Role 或者 ClusterRole 对象。
授予他们在所创建/更新角色中包含特殊权限的权限:
隐式地为他们授权(如果它们试图创建或者更改 Role 或 ClusterRole 的权限,
但自身没有被授予相应权限,API 请求将被禁止)。
通过允许他们在 Role 或 ClusterRole 资源上执行 escalate
动作显式完成授权。
这里的 roles
和 clusterroles
资源包含在 rbac.authorization.k8s.io
API 组中。
对角色绑定创建或更新的限制
只有你已经具有了所引用的角色中包含的全部权限时,或者你被授权在所引用的角色上执行 bind
动词时,你才可以创建或更新角色绑定。这里的权限与角色绑定的作用域相同。
例如,如果用户 user-1
没有列举集群范围所有 Secret 的能力,则他不可以创建
ClusterRoleBinding 引用授予该许可权限的角色。
如要允许用户创建或更新角色绑定:
赋予他们一个角色,使得他们能够根据需要创建或更新 RoleBinding 或 ClusterRoleBinding
对象。
授予他们绑定某特定角色所需要的许可权限:
隐式授权下,可以将角色中包含的许可权限授予他们;
显式授权下,可以授权他们在特定 Role (或 ClusterRole)上执行 bind
动词的权限。
例如,下面的 ClusterRole 和 RoleBinding 将允许用户 user-1
把名字空间 user-1-namespace
中的 admin
、edit
和 view
角色赋予其他用户:
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRole
metadata :
name : role-grantor
rules :
- apiGroups : ["rbac.authorization.k8s.io" ]
resources : ["rolebindings" ]
verbs : ["create" ]
- apiGroups : ["rbac.authorization.k8s.io" ]
resources : ["clusterroles" ]
verbs : ["bind" ]
# 忽略 resourceNames 意味着允许绑定任何 ClusterRole
resourceNames : ["admin" ,"edit" ,"view" ]
---
apiVersion : rbac.authorization.k8s.io/v1
kind : RoleBinding
metadata :
name : role-grantor-binding
namespace : user-1-namespace
roleRef :
apiGroup : rbac.authorization.k8s.io
kind : ClusterRole
name : role-grantor
subjects :
- apiGroup : rbac.authorization.k8s.io
kind : User
name : user-1
当启动引导第一个角色和角色绑定时,需要为初始用户授予他们尚未拥有的权限。
对初始角色和角色绑定进行初始化时需要:
使用用户组为 system:masters
的凭据,该用户组由默认绑定关联到 cluster-admin
这个超级用户角色。
如果你的 API 服务器启动时启用了不安全端口(使用 --insecure-port
), 你也可以通过
该端口调用 API ,这样的操作会绕过身份验证或鉴权。
一些命令行工具
kubectl create role
创建 Role 对象,定义在某一名字空间中的权限。例如:
kubectl create clusterrole
创建 ClusterRole 对象。例如:
kubectl create rolebinding
在特定的名字空间中对 Role
或 ClusterRole
授权。例如:
kubectl create clusterrolebinding
在整个集群(所有名字空间)中用 ClusterRole 授权。例如:
kubectl auth reconcile
使用清单文件来创建或者更新 rbac.authorization.k8s.io/v1
API 对象。
尚不存在的对象会被创建,如果对应的名字空间也不存在,必要的话也会被创建。
已经存在的角色会被更新,使之包含输入对象中所给的权限。如果指定了
--remove-extra-permissions
,可以删除额外的权限。
已经存在的绑定也会被更新,使之包含输入对象中所给的主体。如果指定了
--remove-extra-permissions
,则可以删除多余的主体。
例如:
查看 CLI 帮助获取详细的用法。
服务账户权限
默认的 RBAC 策略为控制面组件、节点和控制器授予权限。
但是不会对 kube-system
名字空间之外的服务账户授予权限。
(除了授予所有已认证用户的发现权限)
这使得你可以根据需要向特定服务账户授予特定权限。
细粒度的角色绑定可带来更好的安全性,但需要更多精力管理。
粗粒度的授权可能导致服务账户被授予不必要的 API 访问权限(甚至导致潜在的权限提升),
但更易于管理。
按从最安全到最不安全的顺序,存在以下方法:
为特定应用的服务账户授予角色(最佳实践)
这要求应用在其 Pod 规约中指定 serviceAccountName
,
并额外创建服务账户(包括通过 API、应用程序清单、kubectl create serviceaccount
等)。
例如,在名字空间 "my-namespace" 中授予服务账户 "my-sa" 只读权限:
kubectl create rolebinding my-sa-view \
--clusterrole= view \
--serviceaccount= my-namespace:my-sa \
--namespace= my-namespace
将角色授予某名字空间中的 "default" 服务账户
如果某应用没有指定 serviceAccountName
,那么它将使用 "default" 服务账户。
说明: "default" 服务账户所具有的权限会被授予给名字空间中所有未指定
serviceAccountName
的 Pod。
例如,在名字空间 "my-namespace" 中授予服务账户 "default" 只读权限:
kubectl create rolebinding default-view \
--clusterrole= view \
--serviceaccount= my-namespace:default \
--namespace= my-namespace
许多插件组件 在 kube-system
名字空间以 "default" 服务账户运行。
要允许这些插件组件以超级用户权限运行,需要将集群的 cluster-admin
权限授予
kube-system
名字空间中的 "default" 服务账户。
说明: 启用这一配置意味着在 kube-system
名字空间中包含以超级用户账号来访问 API
的 Secrets。
kubectl create clusterrolebinding add-on-cluster-admin \
--clusterrole= cluster-admin \
--serviceaccount= kube-system:default
将角色授予名字空间中所有服务账户
如果你想要名字空间中所有应用都具有某角色,无论它们使用的什么服务账户,
可以将角色授予该名字空间的服务账户组。
例如,在名字空间 "my-namespace" 中的只读权限授予该名字空间中的所有服务账户:
kubectl create rolebinding serviceaccounts-view \
--clusterrole= view \
--group= system:serviceaccounts:my-namespace \
--namespace= my-namespace
在集群范围内为所有服务账户授予一个受限角色(不鼓励)
如果你不想管理每一个名字空间的权限,你可以向所有的服务账户授予集群范围的角色。
例如,为集群范围的所有服务账户授予跨所有名字空间的只读权限:
kubectl create clusterrolebinding serviceaccounts-view \
--clusterrole= view \
--group= system:serviceaccounts
授予超级用户访问权限给集群范围内的所有服务帐户(强烈不鼓励)
如果你不关心如何区分权限,你可以将超级用户访问权限授予所有服务账户。
警告: 这样做会允许所有应用都对你的集群拥有完全的访问权限,并将允许所有能够读取
Secret(或创建 Pod)的用户对你的集群有完全的访问权限。
kubectl create clusterrolebinding serviceaccounts-cluster-admin \
--clusterrole= cluster-admin \
--group= system:serviceaccounts
Endpoints 写权限
在 Kubernetes v1.22 之前版本创建的集群里,
"edit" 和 "admin" 聚合角色包含对 Endpoints 的写权限。
作为 CVE-2021-25740 的缓解措施,
此访问权限不包含在 Kubernetes 1.22 以及更高版本集群的聚合角色里。
升级到 Kubernetes v1.22 版本的现有集群不会包括此变化。
CVE 公告
包含了在现有集群里限制此访问权限的指引。
如果你希望在新集群的聚合角色里保留此访问权限,你可以创建下面的 ClusterRole:
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRole
metadata :
annotations :
kubernetes.io/description : |-
Add endpoints write permissions to the edit and admin roles. This was
removed by default in 1.22 because of CVE-2021-25740. See
https://issue.k8s.io/103675. This can allow writers to direct LoadBalancer
or Ingress implementations to expose backend IPs that would not otherwise
be accessible, and can circumvent network policies or security controls
intended to prevent/isolate access to those backends.
labels :
rbac.authorization.k8s.io/aggregate-to-edit : "true"
name : custom:aggregate-to-edit:endpoints # you can change this if you wish
rules :
- apiGroups : ["" ]
resources : ["endpoints" ]
verbs : ["create" , "delete" , "deletecollection" , "patch" , "update" ]
从 ABAC 升级
原来运行较老版本 Kubernetes 的集群通常会使用限制宽松的 ABAC 策略,
包括授予所有服务帐户全权访问 API 的能力。
默认的 RBAC 策略为控制面组件、节点和控制器等授予有限的权限,但不会为
kube-system
名字空间外的服务账户授权
(除了授予所有认证用户的发现权限之外)。
这样做虽然安全得多,但可能会干扰期望自动获得 API 权限的现有工作负载。
这里有两种方法来完成这种转换:
并行鉴权
同时运行 RBAC 和 ABAC 鉴权模式, 并指定包含
现有的 ABAC 策略
的策略文件:
--authorization-mode= RBAC,ABAC --authorization-policy-file= mypolicy.json
关于命令行中的第一个选项:如果早期的鉴权组件,例如 Node,拒绝了某个请求,则
RBAC 鉴权组件尝试对该 API 请求鉴权。如果 RBAC 也拒绝了该 API 请求,则运行 ABAC
鉴权组件。这意味着被 RBAC 或 ABAC 策略所允许的任何请求都是被允许的请求。
如果 API 服务器启动时,RBAC 组件的日志级别为 5 或更高(--vmodule=rbac*=5
或 --v=5
),
你可以在 API 服务器的日志中看到 RBAC 的细节 (前缀 RBAC:
)
你可以使用这些信息来确定需要将哪些角色授予哪些用户、组或服务帐户。
一旦你将角色授予服务账户 ,工作负载运行时
在服务器日志中没有出现 RBAC 拒绝消息,就可以删除 ABAC 鉴权器。
宽松的 RBAC 权限
你可以使用 RBAC 角色绑定在多个场合使用宽松的策略。
警告:
下面的策略允许 所有 服务帐户充当集群管理员。
容器中运行的所有应用程序都会自动收到服务帐户的凭据,可以对 API 执行任何操作,
包括查看 Secrets 和修改权限。这一策略是不被推荐的。
kubectl create clusterrolebinding permissive-binding \
--clusterrole= cluster-admin \
--user= admin \
--user= kubelet \
--group= system:serviceaccounts
在你完成到 RBAC 的迁移后,应该调整集群的访问控制,确保相关的策略满足你的
信息安全需求。
3.9 - 使用 Node 鉴权
节点鉴权是一种特殊用途的鉴权模式,专门对 kubelet 发出的 API 请求进行鉴权。
概述
节点鉴权器允许 kubelet 执行 API 操作。包括:
读取操作:
services
endpoints
nodes
pods
secrets、configmaps、pvcs 以及绑定到 kubelet 节点的与 pod 相关的持久卷
写入操作:
节点和节点状态(启用 NodeRestriction
准入插件以限制 kubelet 只能修改自己的节点)
Pod 和 Pod 状态 (启用 NodeRestriction
准入插件以限制 kubelet 只能修改绑定到自身的 Pod)
事件
鉴权相关操作:
在将来的版本中,节点鉴权器可能会添加或删除权限,以确保 kubelet 具有正确操作所需的最小权限集。
为了获得节点鉴权器的授权,kubelet 必须使用一个凭证以表示它在 system:nodes
组中,用户名为 system:node:<nodeName>
。
上述的组名和用户名格式要与 kubelet TLS 启动引导 过程中为每个 kubelet 创建的标识相匹配。
要启用节点授权器,请使用 --authorization-mode = Node
启动 apiserver。
要限制 kubelet 具有写入权限的 API 对象,请使用 --enable-admission-plugins=...,NodeRestriction,...
启动 apiserver,从而启用 NodeRestriction 准入插件。
迁移考虑因素
在 system:nodes
组之外的 Kubelet
system:nodes
组之外的 kubelet 不会被 Node
鉴权模式授权,并且需要继续通过当前授权它们的机制来授权。
节点准入插件不会限制来自这些 kubelet 的请求。
具有无差别用户名的 Kubelet
在一些部署中,kubelet 具有 system:nodes
组的凭证,但是无法给出它们所关联的节点的标识,因为它们没有 system:node:...
格式的用户名。
这些 kubelet 不会被 Node
授权模式授权,并且需要继续通过当前授权它们的任何机制来授权。
因为默认的节点标识符实现不会把它当作节点身份标识,NodeRestriction
准入插件会忽略来自这些 kubelet 的请求。
相对于以前使用 RBAC 的版本的更新
升级的 1.7 之前的使用 RBAC 的集群将继续按原样运行,因为 system:nodes
组绑定已经存在。
如果集群管理员希望开始使用 Node
鉴权器和 NodeRestriction
准入插件来限制节点对 API 的访问,这一需求可以通过下列操作来完成且不会影响已部署的应用:
启用 Node
鉴权模式 (--authorization-mode=Node,RBAC
) 和 NodeRestriction
准入插件
确保所有 kubelet 的凭据符合组/用户名要求
审核 apiserver 日志以确保 Node
鉴权器不会拒绝来自 kubelet 的请求(日志中没有持续的 NODE DENY
消息)
删除 system:node
集群角色绑定
RBAC 节点权限
在 1.6 版本中,当使用 RBAC 鉴权模式 时,system:nodes
集群角色会被自动绑定到 system:node
组。
在 1.7 版本中,不再推荐将 system:nodes
组自动绑定到 system:node
角色,因为节点鉴权器通过对 secret 和 configmap 访问的额外限制完成了相同的任务。
如果同时启用了 Node
和 RBAC
授权模式,1.7 版本则不会创建 system:nodes
组到 system:node
角色的自动绑定。
在 1.8 版本中,绑定将根本不会被创建。
使用 RBAC 时,将继续创建 system:node
集群角色,以便与将其他用户或组绑定到该角色的部署方法兼容。
3.10 - Webhook 模式
WebHook 是一种 HTTP 回调:某些条件下触发的 HTTP POST 请求;通过 HTTP POST 发送的简单事件通知。一个基于 web 应用实现的 WebHook 会在特定事件发生时把消息发送给特定的 URL。
具体来说,当在判断用户权限时,Webhook
模式会使 Kubernetes 查询外部的 REST 服务。
配置文件格式
Webhook
模式需要一个 HTTP 配置文件,通过 --authorization-webhook-config-file=SOME_FILENAME
的参数声明。
配置文件的格式使用 kubeconfig 。在文件中,"users" 代表着 API 服务器的 webhook,而 "cluster" 代表着远程服务。
使用 HTTPS 客户端认证的配置例子:
# Kubernetes API 版本
apiVersion : v1
# API 对象种类
kind : Config
# clusters 代表远程服务。
clusters :
- name : name-of-remote-authz-service
cluster :
# 对远程服务进行身份认证的 CA。
certificate-authority : /path/to/ca.pem
# 远程服务的查询 URL。必须使用 'https'。
server : https://authz.example.com/authorize
# users 代表 API 服务器的 webhook 配置
users :
- name : name-of-api-server
user :
client-certificate : /path/to/cert.pem # webhook plugin 使用 cert
client-key : /path/to/key.pem # cert 所对应的 key
# kubeconfig 文件必须有 context。需要提供一个给 API 服务器。
current-context : webhook
contexts :
- context :
cluster : name-of-remote-authz-service
user : name-of-api-server
name : webhook
请求载荷
在做认证决策时,API 服务器会 POST 一个 JSON 序列化的 authorization.k8s.io/v1beta1
SubjectAccessReview
对象来描述这个动作。这个对象包含了描述用户请求的字段,同时也包含了需要被访问资源或请求特征的具体信息。
需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都服从版本兼容规则 。实施人员应该了解 beta 对象的更宽松的兼容性承诺,同时确认请求的 "apiVersion" 字段能被正确地反序列化。此外,API 服务器还必须启用 authorization.k8s.io/v1beta1
API 扩展组 (--runtime-config=authorization.k8s.io/v1beta1=true
)。
一个请求内容的例子:
{
"apiVersion" : "authorization.k8s.io/v1beta1" ,
"kind" : "SubjectAccessReview" ,
"spec" : {
"resourceAttributes" : {
"namespace" : "kittensandponies" ,
"verb" : "get" ,
"group" : "unicorn.example.org" ,
"resource" : "pods"
},
"user" : "jane" ,
"group" : [
"group1" ,
"group2"
]
}
}
期待远程服务填充请求的 status
字段并响应允许或禁止访问。响应主体的 spec
字段被忽略,可以省略。允许的响应将返回:
{
"apiVersion" : "authorization.k8s.io/v1beta1" ,
"kind" : "SubjectAccessReview" ,
"status" : {
"allowed" : true
}
}
为了禁止访问,有两种方法。
在大多数情况下,第一种方法是首选方法,它指示授权 webhook 不允许或对请求"无意见",但是,如果配置了其他授权者,则可以给他们机会允许请求。如果没有其他授权者,或者没有一个授权者,则该请求被禁止。webhook 将返回:
{
"apiVersion" : "authorization.k8s.io/v1beta1" ,
"kind" : "SubjectAccessReview" ,
"status" : {
"allowed" : false ,
"reason" : "user does not have read access to the namespace"
}
}
第二种方法立即拒绝其他配置的授权者进行短路评估。仅应由对集群的完整授权者配置有详细了解的 webhook 使用。webhook 将返回:
{
"apiVersion" : "authorization.k8s.io/v1beta1" ,
"kind" : "SubjectAccessReview" ,
"status" : {
"allowed" : false ,
"denied" : true ,
"reason" : "user does not have read access to the namespace"
}
}
对于非资源的路径访问是这么发送的:
{
"apiVersion" : "authorization.k8s.io/v1beta1" ,
"kind" : "SubjectAccessReview" ,
"spec" : {
"nonResourceAttributes" : {
"path" : "/debug" ,
"verb" : "get"
},
"user" : "jane" ,
"group" : [
"group1" ,
"group2"
]
}
}
非资源类的路径包括:/api
, /apis
, /metrics
, /resetMetrics
,
/logs
, /debug
, /healthz
, /swagger-ui/
, /swaggerapi/
, /ui
, 和
/version
。客户端需要访问 /api
, /api/*
, /apis
, /apis/*
, 和 /version
以便
能发现服务器上有什么资源和版本。对于其他非资源类的路径访问在没有 REST API 访问限制的情况下拒绝。
更多信息可以参考 authorization.v1beta1 API 对象和 webhook.go 。
3.11 - 从 PodSecurityPolicy 映射到 Pod 安全性标准
下面的表格列举了PodSecurityPolicy
对象上的配置参数,这些字段是否会变更或检查 Pod 配置,以及这些配置值如何映射到
Pod 安全性标准(Pod Security Standards)
之上。
对于每个可应用的参数,表格中给出了
Baseline 和
Restricted
配置下可接受的取值。
对这两种配置而言不可接受的取值均归入
Privileged
配置下。“无意见”意味着对所有 Pod 安全性标准而言所有取值都可接受。
如果想要了解如何一步步完成迁移,可参阅
从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器 。
PodSecurityPolicy 规约
下面表格中所列举的字段是 PodSecurityPolicySpec
的一部分,是通过 .spec
字段路径来设置的。
从 PodSecurityPolicySpec 字段映射到 Pod Security 标准
PodSecurityPolicySpec
类型
Pod 安全性标准中对应设置
privileged
检查性质
Baseline & Restricted : false
/ 未定义 / nil
defaultAddCapabilities
更改性质 & 检查性质
需求满足下面的 allallowedCapabilities
allowedCapabilities
检查性质
Baseline :下面各项的子集
AUDIT_WRITE
CHOWN
DAC_OVERRIDE
FOWNER
FSETID
KILL
MKNOD
NET_BIND_SERVICE
SETFCAP
SETGID
SETPCAP
SETUID
SYS_CHROOT
Restricted :空 / 未定义 / nil 或仅 包含 NET_BIND_SERVICE
的列表
requiredDropCapabilities
更改性质 & 检查性质
Baseline :无意见
Restricted :必须包含 ALL
volumes
检查性质
Baseline 除下列取值之外的任何值
Restricted :下列取值的子集
configMap
csi
downwardAPI
emptyDir
ephemeral
persistentVolumeClaim
projected
secret
hostNetwork
检查性质
Baseline & Restricted :false
/ 未定义 / nil
hostPorts
检查性质
Baseline & Restricted :未定义 / nil / 空
hostPID
检查性质
Baseline & Restricted :false
/ 未定义 / nil
hostIPC
检查性质
Baseline & Restricted :false
/ 未定义 / nil
seLinux
更改性质 & 检查性质
Baseline & Restricted :
seLinux.rule
为 MustRunAs
,且 options
如下:
user
未设置(""
/ 未定义 / nil)
role
未设置(""
/ 未定义 / nil)
type
未设置或者取值为 container_t
、container_init_t
或 container_kvm_t
之一
level
是任何取值
runAsUser
变更性质 & 检查性质
Baseline :任何取值
Restricted :rule
是 MustRunAsNonRoot
runAsGroup
变更性质(MustRunAs)& 检查性质
无意见
supplementalGroups
变更性质 & 检查性质
无意见
fsGroup
变更性质 & 验证性质
无意见
readOnlyRootFilesystem
变更性质 & 检查性质
无意见
defaultAllowPrivilegeEscalation
变更性质
无意见(非变更性质)
allowPrivilegeEscalation
变更性质 & 检查性质
只有设置为 false
时才执行变更动作
Baseline :无意见
Restricted :false
allowedHostPaths
检查性质
无意见(volumes 优先)
allowedFlexVolumes
检查性质
无意见(volumes 优先)
allowedCSIDrivers
检查性质
无意见(volumes 优先)
allowedUnsafeSysctls
检查性质
Baseline & Restricted :未定义 / nil / 空
forbiddenSysctls
检查性质
无意见
allowedProcMountTypes
(alpha feature)
检查性质
Baseline & Restricted :["Default"]
或者未定义 / nil / 空
runtimeClass
.defaultRuntimeClassName
变更性质
无意见
runtimeClass
.allowedRuntimeClassNames
检查性质
无意见
PodSecurityPolicy 注解
下面表格中所列举的注解
可以通过 .metadata.annotations
设置到 PodSecurityPolicy 对象之上。
将 PodSecurityPolicy 注解映射到 Pod 安全性标准
PSP 注解
类型
Pod 安全性标准中对应设置
seccomp.security.alpha.kubernetes.io
/defaultProfileName
变更性质
无意见
seccomp.security.alpha.kubernetes.io
/allowedProfileNames
检查性质
Baseline :"runtime/default,"
(其中尾部的逗号允许取消设置)
Restricted :"runtime/default"
(没有尾部逗号)
localhost/*
取值对于 Baseline 和 Restricted 都是可接受的
apparmor.security.beta.kubernetes.io
/defaultProfileName
变更性质
无意见
apparmor.security.beta.kubernetes.io
/allowedProfileNames
检查性质
Baseline :"runtime/default,"
(其中尾部的逗号允许取消设置)
Restricted :"runtime/default"
(没有尾部逗号)
localhost/*
取值对于 Baseline 和 Restricted 都是可接受的
3.12 - 使用 ABAC 鉴权
基于属性的访问控制(Attribute-based access control - ABAC)定义了访问控制范例,其中通过使用将属性组合在一起的策略来向用户授予访问权限。
策略文件格式
基于 ABAC
模式,可以这样指定策略文件 --authorization-policy-file=SOME_FILENAME
。
此文件格式是 JSON Lines ,不应存在外层的列表或映射,每行应只有一个映射。
每一行都是一个策略对象,策略对象是具有以下属性的映射:
版本控制属性:
apiVersion
,字符串类型:有效值为abac.authorization.kubernetes.io/v1beta1
,允许对策略格式进行版本控制和转换。
kind
,字符串类型:有效值为 Policy
,允许对策略格式进行版本控制和转换。
spec
配置为具有以下映射的属性:
主体匹配属性:
user
,字符串类型;来自 --token-auth-file
的用户字符串,如果你指定 user
,它必须与验证用户的用户名匹配。
group
,字符串类型;如果指定 group
,它必须与经过身份验证的用户的一个组匹配,system:authenticated
匹配所有经过身份验证的请求。system:unauthenticated
匹配所有未经过身份验证的请求。
资源匹配属性:
apiGroup
,字符串类型;一个 API 组。
例: extensions
通配符:*
匹配所有 API 组。
namespace
,字符串类型;一个命名空间。
例如:kube-system
通配符:*
匹配所有资源请求。
resource
,字符串类型;资源类型。
非资源匹配属性:
nonResourcePath
,字符串类型;非资源请求路径。
例如:/version
或 /apis
通配符:
*
匹配所有非资源请求。
/foo/*
匹配 /foo/
的所有子路径。
readonly
,键入布尔值,如果为 true,则表示该策略仅适用于 get、list 和 watch 操作。
说明:
属性未设置等效于属性被设置为对应类型的零值( 例如空字符串、0、false),然而,出于可读性考虑,应尽量选择不设置这类属性。
在将来,策略可能以 JSON 格式表示,并通过 REST 界面进行管理。
鉴权算法
请求具有与策略对象的属性对应的属性。
当接收到请求时,确定属性。未知属性设置为其类型的零值(例如:空字符串,0,false)。
设置为 "*"
的属性将匹配相应属性的任何值。
检查属性的元组,以匹配策略文件中的每个策略。如果至少有一行匹配请求属性,则请求被鉴权(但仍可能无法通过稍后的合法性检查)。
要允许任何经过身份验证的用户执行某些操作,请将策略组属性设置为 "system:authenticated"
。
要允许任何未经身份验证的用户执行某些操作,请将策略组属性设置为 "system:authentication"
。
要允许用户执行任何操作,请使用 apiGroup,命名空间,
资源和 nonResourcePath 属性设置为 "*"
的策略。
要允许用户执行任何操作,请使用设置为 "*"
的 apiGroup,namespace,resource 和 nonResourcePath 属性编写策略。
Kubectl
Kubectl 使用 api-server 的 /api
和 /apis
端点来发现服务资源类型,并使用位于 /openapi/v2
的模式信息来验证通过创建/更新操作发送到 API 的对象。
当使用 ABAC 鉴权时,这些特殊资源必须显式地通过策略中的 nonResourcePath
属性暴露出来(参见下面的 示例 ):
/api
,/api/*
,/apis
和 /apis/*
用于 API 版本协商。
/version
通过 kubectl version
检索服务器版本。
/swaggerapi/*
用于创建 / 更新操作。
要检查涉及到特定 kubectl 操作的 HTTP 调用,您可以调整详细程度:
kubectl --v=8 version
例子
Alice 可以对所有资源做任何事情:
{"apiVersion" : "abac.authorization.kubernetes.io/v1beta1" , "kind" : "Policy" , "spec" : {"user" : "alice" , "namespace" : "*" , "resource" : "*" , "apiGroup" : "*" }}
Kubelet 可以读取任何 pod:
{"apiVersion" : "abac.authorization.kubernetes.io/v1beta1" , "kind" : "Policy" , "spec" : {"user" : "kubelet" , "namespace" : "*" , "resource" : "pods" , "readonly" : true }}
Kubelet 可以读写事件:
{"apiVersion" : "abac.authorization.kubernetes.io/v1beta1" , "kind" : "Policy" , "spec" : {"user" : "kubelet" , "namespace" : "*" , "resource" : "events" }}
Bob 可以在命名空间 projectCaribou
中读取 pod:
{"apiVersion" : "abac.authorization.kubernetes.io/v1beta1" , "kind" : "Policy" , "spec" : {"user" : "bob" , "namespace" : "projectCaribou" , "resource" : "pods" , "readonly" : true }}
任何人都可以对所有非资源路径进行只读请求:
{"apiVersion" : "abac.authorization.kubernetes.io/v1beta1" , "kind" : "Policy" , "spec" : {"group" : "system:authenticated" , "readonly" : true , "nonResourcePath" : "*" }}
{"apiVersion" : "abac.authorization.kubernetes.io/v1beta1" , "kind" : "Policy" , "spec" : {"group" : "system:unauthenticated" , "readonly" : true , "nonResourcePath" : "*" }}
完整文件示例
服务帐户的快速说明
服务帐户自动生成用户。用户名是根据命名约定生成的:
system:serviceaccount:<namespace>:<serviceaccountname>
创建新的命名空间也会导致创建一个新的服务帐户:
system:serviceaccount:<namespace>:default
例如,如果要将 API 的 kube-system 完整权限中的默认服务帐户授予,则可以将此行添加到策略文件中:
{"apiVersion" :"abac.authorization.kubernetes.io/v1beta1" ,"kind" :"Policy" ,"spec" :{"user" :"system:serviceaccount:kube-system:default" ,"namespace" :"*" ,"resource" :"*" ,"apiGroup" :"*" }}
需要重新启动 apiserver 以获取新的策略行。
4 - 众所周知的标签、注解和污点
Kubernetes 将所有标签和注解保留在 kubernetes.io Namespace中。
本文档既可作为值的参考,也可作为分配值的协调点。
API 对象上使用的标签、注解和污点
kubernetes.io/arch
例子:kubernetes.io/arch=amd64
用于:Node
Kubelet 使用 Go 定义的 runtime.GOARCH
填充它。 如果你混合使用 ARM 和 X86 节点,这会很方便。
kubernetes.io/os
例子:kubernetes.io/os=linux
用于:Node
Kubelet 使用 Go 定义的 runtime.GOOS
填充它。如果你在集群中混合使用操作系统(例如:混合 Linux 和 Windows 节点),这会很方便。
例子:kubernetes.io/metadata.name=mynamespace
用于:Namespace
Kubernetes API 服务器(控制平面 的一部分)在所有 Namespace 上设置此标签。
标签值被设置 Namespace 的名称。你无法更改此标签的值。
如果你想使用标签选择器 定位特定 Namespace,这很有用。
beta.kubernetes.io/arch (已弃用)
此标签已被弃用。请改用kubernetes.io/arch
。
beta.kubernetes.io/os (已弃用)
此标签已被弃用。请改用kubernetes.io/os
。
kubernetes.io/hostname
例子:kubernetes.io/hostname=ip-172-20-114-199.ec2.internal
用于:Node
Kubelet 使用主机名填充此标签。请注意,可以通过将 --hostname-override
标志传递给 kubelet
来替代“实际”主机名。
此标签也用作拓扑层次结构的一部分。 有关详细信息,请参阅 topology.kubernetes.io/zone 。
kubernetes.io/change-cause
例子:kubernetes.io/change-cause=kubectl edit --record deployment foo
用于:所有对象
此注解是对某些事物发生变更的原因的最佳猜测。
将 --record
添加到可能会更改对象的 kubectl
命令时会填充它。
kubernetes.io/description
例子:kubernetes.io/description: "Description of K8s object."
用于:所有对象
此注解用于描述给定对象的特定行为。
kubernetes.io/enforce-mountable-secrets
例子:kubernetes.io/enforce-mountable-secrets: "true"
用于:ServiceAccount
此注解的值必须为 true 才能生效。此注解表示作为此服务帐户运行的 Pod 只能引用在服务帐户的 secrets
字段中指定的 Secret API 对象。
controller.kubernetes.io/pod-deletion-cost
例子:controller.kubernetes.io/pod-deletion-cost=10
用于:Pod
该注解用于设置 Pod 删除成本 允许用户影响 ReplicaSet 缩减顺序。注解解析为 int32
类型。
beta.kubernetes.io/instance-type (已弃用)
node.kubernetes.io/instance-type
例子:node.kubernetes.io/instance-type=m3.medium
用于:Node
Kubelet 使用 cloudprovider
定义的实例类型填充它。
仅当你使用 cloudprovider
时才会设置此项。如果你希望将某些工作负载定位到某些实例类型,则此设置非常方便,但通常你希望依靠 Kubernetes 调度程序来执行基于资源的调度。
你应该基于属性而不是实例类型来调度(例如:需要 GPU,而不是需要 g2.2xlarge
)。
failure-domain.beta.kubernetes.io/region (已弃用)
请参阅 topology.kubernetes.io/region 。
failure-domain.beta.kubernetes.io/zone (已弃用)
请参阅 topology.kubernetes.io/zone 。
statefulset.kubernetes.io/pod-name
例子:statefulset.kubernetes.io/pod-name=mystatefulset-7
当 StatefulSet 控制器为 StatefulSet 创建 Pod 时,控制平面会在该 Pod 上设置此标签。标签的值是正在创建的 Pod 的名称。
有关详细信息,请参阅 StatefulSet 主题中的 Pod 名称标签 。
topology.kubernetes.io/region
例子:topology.kubernetes.io/region=us-east-1
请参阅 topology.kubernetes.io/zone 。
topology.kubernetes.io/zone
例子:topology.kubernetes.io/zone=us-east-1c
用于:Node、PersistentVolume
在 Node 上:kubelet
或外部 cloud-controller-manager
使用 cloudprovider
提供的信息填充它。仅当你使用 cloudprovider
时才会设置此项。
但是,如果它在你的拓扑中有意义,你应该考虑在 Node 上设置它。
在 PersistentVolume 上:拓扑感知卷配置器将自动在 PersistentVolume
上设置 Node 亲和性约束。
一个 Zone 代表一个逻辑故障域。 Kubernetes 集群通常跨越多个 Zone 以提高可用性。虽然 Zone 的确切定义留给基础设施实现,
但 Zone 的常见属性包括 Zone 内非常低的网络延迟、 Zone 内的免费网络流量以及与其他 Zone 的故障独立性。
例如,一个 Zone 内的 Node 可能共享一个网络交换机,但不同 Zone 中的 Node 无法共享交换机。
一个 Region 代表一个更大的域,由一个或多个 Zone 组成。Kubernetes 集群跨多个 Region 并不常见,虽然 Zone 或 Region 的确切定义留给基础设施实现,
但 Region 的共同属性包括它们之间的网络延迟比它们内部更高,它们之间的网络流量成本非零,以及与其他 Zone 或 Region 的故障独立性。
例如,一个 Region 内的 Node 可能共享电力基础设施(例如 UPS 或发电机),但不同 Region 的 Node 通常不会共享电力基础设施。
Kubernetes 对 Zone 和 Region 的结构做了一些假设:
Zone 和 Region 是分层的: Zone 是 Region 的严格子集,没有 Zone 可以在两个 Region 中;
Zone 名称跨 Region 是唯一的;例如, Region “africa-east-1” 可能由 Zone “africa-east-1a” 和 “africa-east-1b” 组成。
你可以大胆假设拓扑标签不会改变。尽管严格地讲标签是可变的,但节点的用户可以假设给定
节点只能通过销毁和重新创建才能完成 Zone 间移动。
Kubernetes 可以通过多种方式使用这些信息。例如,调度程序会自动尝试将 ReplicaSet 中的 Pod
分布在单 Zone 集群中的多个节点上(以便减少节点故障的影响,请参阅 kubernetes.io/hostname )。
对于多 Zone 集群,这种分布行为也适用于 Zone(以减少 Zone 故障的影响)。
Zone 级别的 Pod 分布是通过 SelectorSpreadPriority 实现的。
SelectorSpreadPriority 是一个尽力而为的放置机制。如果集群中的 Zone 是异构的
(例如:节点数量不同、节点类型不同或 Pod 资源需求有别等),这种放置机制可能会让你的
Pod 无法实现跨 Zone 均匀分布。
如果需要,你可以使用同质 Zone(节点数量和类型均相同)来减少不均匀分布的可能性。
调度程序还将(通过 VolumeZonePredicate 条件)确保申领给定卷的 Pod 仅被放置在与该卷相同的 Zone 中。
卷不能跨 Zone 挂接。
你应该考虑手动添加标签(或添加对 PersistentVolumeLabel
的支持)。
基于 PersistentVolumeLabel
,调度程序可以防止 Pod 挂载来自其他 Zone 的卷。如果你的基础架构没有此限制,则不需要将 Zone 标签添加到卷上。
volume.beta.kubernetes.io/storage-provisioner (已弃用)
例子:volume.beta.kubernetes.io/storage-provisioner: k8s.io/minikube-hostpath
用于:PersistentVolumeClaim
此注解已被弃用。
volume.kubernetes.io/storage-provisioner
用于:PersistentVolumeClaim
此注解将被添加到根据需要动态制备的 PVC 上。
node.kubernetes.io/windows-build
例子:node.kubernetes.io/windows-build=10.0.17763
用于:Node
当 kubelet 在 Microsoft Windows 上运行时,它会自动标记其所在节点以记录所使用的 Windows Server 的版本。
标签的值采用 “MajorVersion.MinorVersion.BuildNumber” 格式。
service.kubernetes.io/headless
例子:service.kubernetes.io/headless=""
用于:Service
当拥有的 Service 是无头类型时,控制平面将此标签添加到 Endpoints 对象。
kubernetes.io/service-name
例子:kubernetes.io/service-name="nginx"
用于:Service
Kubernetes 使用这个标签来区分多个服务。目前仅用于 ELB
(弹性负载均衡器)。
endpointslice.kubernetes.io/managed-by
例子:endpointslice.kubernetes.io/managed-by="controller"
用于:EndpointSlice
用于标示管理 EndpointSlice 的控制器或实体。该标签旨在使不同的 EndpointSlice
对象能够由同一集群内的不同控制器或实体管理。
endpointslice.kubernetes.io/skip-mirror
例子:endpointslice.kubernetes.io/skip-mirror="true"
用于:Endpoints
可以在 Endpoints 资源上将此标签设置为 "true"
,以指示 EndpointSliceMirroring
控制器不应使用 EndpointSlice 镜像此 Endpoints 资源。
service.kubernetes.io/service-proxy-name
例子:service.kubernetes.io/service-proxy-name="foo-bar"
用于:Service
kube-proxy 自定义代理会使用这个标签,它将服务控制委托给自定义代理。
experimental.windows.kubernetes.io/isolation-type (已弃用)
例子:experimental.windows.kubernetes.io/isolation-type: "hyperv"
用于:Pod
注解用于运行具有 Hyper-V 隔离的 Windows 容器。要使用 Hyper-V 隔离功能并创建 Hyper-V
隔离容器,kubelet 启动时应该需要设置特性门控 HyperVContainer=true。
说明: 你只能在具有单个容器的 Pod 上设置此注解。
从 v1.20 开始,此注解已弃用。1.21 中删除了实验性 Hyper-V 支持。
ingressclass.kubernetes.io/is-default-class
例子:ingressclass.kubernetes.io/is-default-class: "true"
用于:IngressClass
当单个 IngressClass 资源将此注解设置为 "true"
时,新的未指定 Ingress 类的 Ingress
资源将被设置为此默认类。
kubernetes.io/ingress.class (已弃用)
说明: 从 v1.18 开始,不推荐使用此注解以鼓励使用 spec.ingressClassName
。
storageclass.kubernetes.io/is-default-class
例子:storageclass.kubernetes.io/is-default-class=true
用于:StorageClass
当单个 StorageClass 资源将此注解设置为 "true"
时,新的未指定存储类的 PersistentVolumeClaim
资源将被设置为此默认类。
alpha.kubernetes.io/provided-node-ip
例子:alpha.kubernetes.io/provided-node-ip: "10.0.0.1"
用于:Node
kubelet 可以在 Node 上设置此注解来表示其配置的 IPv4 地址。
当使用“外部”云驱动启动时,kubelet 会在 Node 上设置此注解以表示从命令行标志 ( --node-ip
) 设置的 IP 地址。
云控制器管理器通过云驱动验证此 IP 是否有效。
batch.kubernetes.io/job-completion-index
例子:batch.kubernetes.io/job-completion-index: "3"
用于:Pod
kube-controller-manager 中的 Job 控制器为使用 Indexed
完成模式 创建的 Pod
设置此注解。
kubectl.kubernetes.io/default-container
例子:kubectl.kubernetes.io/default-container: "front-end-app"
此注解的值是此 Pod 的默认容器名称。例如,未指定 -c
或 --container
标志时执行
kubectl logs
或 kubectl exec
命令将使用此默认容器。
endpoints.kubernetes.io/over-capacity
例子:endpoints.kubernetes.io/over-capacity:truncated
用于:Endpoints
在 Kubernetes 集群 v1.22(或更高版本)中,如果 Endpoints 资源超过 1000 个,Endpoints
控制器会将此注解添加到 Endpoints 资源。
注解表示 Endpoints 资源已超出容量,并且已将 Endpoints 数截断为 1000。
batch.kubernetes.io/job-tracking
例子:batch.kubernetes.io/job-tracking: ""
用于:Job
Job 上存在此注解表明控制平面正在使用 Finalizer 追踪 Job 。
你 不 可以手动添加或删除此注解。
scheduler.alpha.kubernetes.io/preferAvoidPods (deprecated)
用于:Node
此注解需要启用 NodePreferAvoidPods 调度插件 。
该插件自 Kubernetes 1.22 起已被弃用。
请改用污点和容忍度 。
下面列出的污点总是在 Node 上使用
node.kubernetes.io/not-ready
例子:node.kubernetes.io/not-ready:NoExecute
Node 控制器通过监控 Node 的健康状况来检测 Node 是否准备就绪,并相应地添加或删除此污点。
node.kubernetes.io/unreachable
例子:node.kubernetes.io/unreachable:NoExecute
Node 控制器将此污点添加到对应节点状况 Ready
为 Unknown
的 Node 上。
node.kubernetes.io/unschedulable
例子:node.kubernetes.io/unschedulable:NoSchedule
在初始化 Node 期间,为避免竞争条件,此污点将被添加到 Node 上。
node.kubernetes.io/memory-pressure
例子:node.kubernetes.io/memory-pressure:NoSchedule
kubelet 根据在 Node 上观察到的 memory.available
和 allocatableMemory.available
检测内存压力。
然后将观察到的值与可以在 kubelet 上设置的相应阈值进行比较,以确定是否应添加/删除 Node 状况和污点。
node.kubernetes.io/disk-pressure
例子:node.kubernetes.io/disk-pressure:NoSchedule
kubelet 根据在 Node 上观察到的 imagefs.available
、imagefs.inodesFree
、nodefs.available
和 nodefs.inodesFree
(仅限 Linux )检测磁盘压力。
然后将观察到的值与可以在 kubelet 上设置的相应阈值进行比较,以确定是否应添加/删除 Node 状况和污点。
node.kubernetes.io/network-unavailable
例子:node.kubernetes.io/network-unavailable:NoSchedule
当使用的云驱动指示需要额外的网络配置时,此注解最初由 kubelet 设置。
只有云上的路由被正确地配置了,此污点才会被云驱动移除
node.kubernetes.io/pid-pressure
例子:node.kubernetes.io/pid-pressure:NoSchedule
kubelet 检查 /proc/sys/kernel/pid_max
大小的 D 值和 Kubernetes 在 Node 上消耗的 PID,
以获取可用 PID 数量,并将其作为 pid.available
指标值。
然后该指标与在 kubelet 上设置的相应阈值进行比较,以确定是否应该添加/删除 Node 状况和污点。
node.cloudprovider.kubernetes.io/uninitialized
例子:node.cloudprovider.kubernetes.io/uninitialized:NoSchedule
在使用“外部”云驱动启动 kubelet 时,在 Node 上设置此污点以将其标记为不可用,直到来自
cloud-controller-manager 的控制器初始化此 Node,然后移除污点。
node.cloudprovider.kubernetes.io/shutdown
例子:node.cloudprovider.kubernetes.io/shutdown:NoSchedule
如果 Node 处于云驱动所指定的关闭状态,则 Node 会相应地被设置污点,对应的污点和效果为
node.cloudprovider.kubernetes.io/shutdown
和 NoSchedule
。
pod-security.kubernetes.io/enforce
例子:pod-security.kubernetes.io/enforce: baseline
用于:Namespace
值必须 是 privileged
、baseline
或 restricted
之一,它们对应于
Pod 安全标准 级别。
特别地,enforce
标签 禁止 在带标签的 Namespace 中创建任何不符合指示级别要求的 Pod。
请请参阅在名字空间级别实施 Pod 安全性 了解更多信息。
pod-security.kubernetes.io/enforce-version
例子:pod-security.kubernetes.io/enforce-version: 1.23
用于:Namespace
值必须 是 latest
或格式为 v<MAJOR>.<MINOR>
的有效 Kubernetes 版本。
此注解决定了在验证提交的 Pod 时要应用的 Pod 安全标准 策略的版本。
请参阅在名字空间级别实施 Pod 安全性 了解更多信息。
pod-security.kubernetes.io/audit
例子:pod-security.kubernetes.io/audit: baseline
用于:Namespace
值必须 是与 Pod 安全标准 级别相对应的
privileged
、baseline
或 restricted
之一。
具体来说,audit
标签不会阻止在带标签的 Namespace 中创建不符合指示级别要求的 Pod,
但会向该 Pod 添加审计注解。
请参阅在名字空间级别实施 Pod 安全性 了解更多信息。
pod-security.kubernetes.io/audit-version
例子:pod-security.kubernetes.io/audit-version: 1.23
用于:Namespace
值必须 是 latest
或格式为 v<MAJOR>.<MINOR>
的有效 Kubernetes 版本。
此注解决定了在验证提交的 Pod 时要应用的 Pod 安全标准 策略的版本。
请参阅在名字空间级别实施 Pod 安全性 了解更多信息。
pod-security.kubernetes.io/warn
例子:pod-security.kubernetes.io/warn: baseline
用于:Namespace
值必须 是与 Pod 安全标准 级别相对应的
privileged
、baseline
或 restricted
之一。特别地,
warn
标签不会阻止在带标签的 Namespace 中创建不符合指示级别概述要求的 Pod,但会在这样做后向用户返回警告。
请注意,在创建或更新包含 Pod 模板的对象时也会显示警告,例如 Deployment、Jobs、StatefulSets 等。
请参阅在名字空间级别实施 Pod 安全性 了解更多信息。
pod-security.kubernetes.io/warn-version
例子:pod-security.kubernetes.io/warn-version: 1.23
用于:Namespace
值必须 是 latest
或格式为 v<MAJOR>.<MINOR>
的有效 Kubernetes 版本。
此注解决定了在验证提交的 Pod 时要应用的 Pod 安全标准 策略的版本。
请注意,在创建或更新包含 Pod 模板的对象时也会显示警告,
例如 Deployment、Jobs、StatefulSets 等。
请参阅在名字空间级别实施 Pod 安全性 了解更多信息。
seccomp.security.alpha.kubernetes.io/pod (已弃用)
此注解自 Kubernetes v1.19 起已被弃用,将在 v1.25 中失效。
要为 Pod 指定安全设置,请在 Pod 规范中包含 securityContext
字段。
Pod 的 .spec
中的 securityContext
字段定义了 Pod 级别的安全属性。
你为 Pod 设置安全上下文 时,
你所给出的设置适用于该 Pod 中的所有容器。
container.seccomp.security.alpha.kubernetes.io/[NAME]
此注解自 Kubernetes v1.19 起已被弃用,将在 v1.25 中失效。
教程使用 seccomp 限制容器的系统调用 将引导你完成将
seccomp 配置文件应用于 Pod 或其容器的步骤。
该教程介绍了在 Kubernetes 中配置 seccomp 的支持机制,基于在 Pod 的 .spec
中设置 securityContext
。
用于审计的注解
在审计注解 页面上查看更多详细信息。
4.1 - 审计注解
该页面作为 kubernetes.io 名字空间的审计注解的参考。这些注解适用于 API 组 audit.k8s.io
中的 Event
对象。
说明: Kubernetes API 中不使用以下注解。当你在集群中
启用审计 时,
审计事件数据将使用 API 组
audit.k8s.io
中的
Event
写入。
注解适用于审计事件。审计事件不同于
事件 API
(API 组
events.k8s.io
)中的对象。
pod-security.kubernetes.io/exempt
例子:pod-security.kubernetes.io/exempt: namespace
值必须 是对应于 Pod 安全豁免 维度的
user
、namespace
或 runtimeClass
之一。
此注解指示 PodSecurity 基于哪个维度的强制豁免执行。
pod-security.kubernetes.io/enforce-policy
例子:pod-security.kubernetes.io/enforce-policy: restricted:latest
值必须 是对应于 Pod 安全标准 级别的
privileged:<版本>
、baseline:<版本>
、restricted:<版本>
,
关联的版本必须 是 latest
或格式为 v<MAJOR>.<MINOR>
的有效 Kubernetes 版本。
此注解通知有关在 PodSecurity 准入期间允许或拒绝 Pod 的执行级别。
有关详细信息,请参阅 Pod 安全标准 。
pod-security.kubernetes.io/audit-violations
例子:pod-security.kubernetes.io/audit-violations: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "example" must set securityContext.allowPrivilegeEscalation=false), ...
注解值给出审计策略违规的详细说明,它包含所违反的 Pod 安全标准 级别以及
PodSecurity 执行中违反的特定策略及对应字段。
有关详细信息,请参阅 Pod 安全标准 。
5 - Kubernetes API
Kubernetes API 是通过 RESTful 接口提供 Kubernetes 功能服务并负责集群状态存储的应用程序。
Kubernetes 资源和"意向记录"都是作为 API 对象储存的,并可以通过调用 RESTful 风格的 API 进行修改。
API 允许以声明方式管理配置。
用户可以直接和 Kubernetes API 交互,也可以通过 kubectl
这样的工具进行交互。
核心的 Kubernetes API 是很灵活的,可以扩展以支持定制资源。
5.1 - 公共定义
5.1.1 - 删除选项
删除 API 对象时可能会提供删除选项。
import "k8s.io/apimachinery/pkg/apis/meta/v1"
删除 API 对象时可能会提供 DeleteOptions。
orphanDependents (boolean)
已弃用:该字段将在 1.7 中弃用,请使用 propagationPolicy
字段。
该字段表示依赖对象是否应该是孤儿。如果为 true/false,对象的 finalizers 列表中会被添加上或者移除掉 “orphan” 终结器(Finalizer)。
可以设置此字段或者设置 propagationPolicy
字段,但不能同时设置以上两个字段。
propagationPolicy (string)
表示是否以及如何执行垃圾收集。可以设置此字段或 orphanDependents
字段,但不能同时设置二者。
默认策略由 metadata.finalizers
中现有终结器(Finalizer)集合和特定资源的默认策略决定。
可接受的值为: Orphan
- 令依赖对象成为孤儿对象;Background
- 允许垃圾收集器在后台删除依赖项;Foreground
- 一个级联策略,前台删除所有依赖项。
5.1.2 - 标签选择器
标签选择器是对一组资源的标签查询。
import "k8s.io/apimachinery/pkg/apis/meta/v1"
标签选择器是对一组资源的标签查询。
matchLabels
和 matchExpressions
的结果按逻辑与的关系组合。一个 empty
标签选择器匹配所有对象。一个 null
标签选择器不匹配任何对象。
matchExpressions ([]LabelSelectorRequirement)
matchExpressions
是 LabelSelectorRequirement
的列表,这些需求结果按逻辑与的关系来计算。
标签选择器要求是包含值、键和关联键和值的运算符的选择器。
matchExpressions.values ([]string)
values
是一个字符串值数组。如果运算符为 In
或 NotIn
,则 values
数组必须为非空。
如果运算符是 Exists
或 DoesNotExist
,则 values
数组必须为空。
该数组在战略性补丁(Strategic Merge Patch)期间被替换。
matchLabels (map[string]string)
matchLabels
是 {key
,value
} 键值对的映射。
matchLabels
映射中的单个 {key
,value
} 键值对相当于 matchExpressions
的一个元素,其键字段为 key
,运算符为 In
,values
数组仅包含 value
。
所表达的需求最终要按逻辑与的关系组合。
5.1.3 - ListMeta
ListMeta 描述了合成资源必须具有的元数据,包括列表和各种状态对象。
import "k8s.io/apimachinery/pkg/apis/meta/v1"
ListMeta
描述了合成资源必须具有的元数据,包括列表和各种状态对象。
一个资源仅能有 {ObjectMeta, ListMeta}
中的一个。
remainingItemCount (int64)
remainingItemCount
是列表中未包含在此列表响应中的后续项目的数量。
如果列表请求包含标签或字段选择器,则剩余项目的数量是未知的,并且在序列化期间该字段将保持未设置和省略。
如果列表是完整的(因为它没有分块或者这是最后一个块),那么就没有剩余的项目,并且在序列化过程中该字段将保持未设置和省略。
早于 v1.15 的服务器不设置此字段。remainingItemCount
的预期用途是估计 集合的大小。
客户端不应依赖于设置准确的 remainingItemCount
。
5.1.4 - LocalObjectReference
LocalObjectReference 包含足够的信息,可以让你在同一命名空间内找到引用的对象。
import "k8s.io/api/core/v1"
LocalObjectReference 包含足够的信息,可以让你在同一命名空间(namespace)内找到引用的对象。
5.1.5 - NodeSelectorRequirement
节点选择器是要求包含键、值和关联键和值的运算符的选择器
import "k8s.io/api/core/v1"
节点选择器是要求包含键、值和关联键和值的运算符的选择器。
key (string), 必选
选择器适用的标签键。
5.1.6 - ObjectFieldSelector
ObjectFieldSelector 选择对象的 APIVersioned 字段。
import "k8s.io/api/core/v1"
ObjectFieldSelector 选择对象的 APIVersioned 字段。
5.1.7 - ObjectReference
ObjectReference 包含足够的信息,可以让你检查或修改引用的对象。
import "k8s.io/api/core/v1"
ObjectReference包含足够的信息,允许你检查或修改引用的对象。
apiVersion (string)
被引用者的 API 版本。
fieldPath (string)
如果引用的是对象的某个对象是整个对象,则该字符串而不是应包含的 JSON/Go 字段有效访问语句,
例如desiredState.manifest.containers[ 2 ]
。例如,如果对象引用针对的是 Pod 中的一个容器,
此字段取值类似于:spec.containers{name}
(name
指触发的容器的名称),
或者如果没有指定容器名称,spec.containers[ 2 ]
(此Pod中索引为2的容器)。
选择这种只是为了有一些定义好的语法来引用对象的部分。
kind (string)
被引用者的类别(kind)。 更多信息:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md #types-kinds
name (string)
被引用对象的名称。更多信息:https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
namespace (string)
被引用对象的名字空间。更多信息:https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
resourceVersion (string)
被引用对象的特定资源版本(如果有)。更多信息:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency
uid (string)
被引用对象的UID。更多信息:https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids
5.1.8 - Patch
提供 Patch 是为了给 Kubernetes PATCH 请求正文提供一个具体的名称和类型。
import "k8s.io/apimachinery/pkg/apis/meta/v1"
提供 Patch 是为了给 Kubernetes PATCH 请求正文提供一个具体的名称和类型。
5.1.9 - Quantity
数量(Quantity)是数字的定点表示。
import "k8s.io/apimachinery/pkg/api/resource"
数量(Quantity)是数字的定点表示。
除了 String() 和 AsInt64() 的访问接口之外,
它以 JSON 和 YAML形式提供方便的打包和解包方法。
序列化格式如下:
<quantity> ::= <signedNumber><suffix>
(注意 <suffix> 可能为空, 例如 <decimalSI> 的 "" 情形。) </br>
<digit> ::= 0 | 1 | ... | 9 </br>
<digits> ::= <digit> | <digit><digits> </br>
<number> ::= <digits> | <digits>.<digits> | <digits>. | .<digits> </br>
<sign> ::= "+" | "-" </br>
<signedNumber> ::= <number> | <sign><number> </br>
<suffix> ::= <binarySI> | <decimalExponent> | <decimalSI> </br>
<binarySI> ::= Ki | Mi | Gi | Ti | Pi | Ei
(国际单位制度;查阅:http://physics.nist.gov/cuu/Units/binary.html) </br>
<decimalSI> ::= m | "" | k | M | G | T | P | E
(注意,1024 = 1ki 但 1000 = 1k;我没有选择大写。) </br>
<decimalExponent> ::= "e" <signedNumber> | "E" <signedNumber> </br>
无论使用三种指数形式中哪一种,没有数量可以表示大于 263 -1 的数,也不可能超过 3 个小数位。
更大或更精确的数字将被截断或向上取整。(例如:0.1m 将向上取整为 1m。)
如果将来我们需要更大或更小的数量,可能会扩展。
当从字符串解析数量时,它将记住它具有的后缀类型,并且在序列化时将再次使用相同类型。
在序列化之前,数量将以“规范形式”放置。这意味着指数或者后缀将被向上或向下调整(尾数相应增加或减少),并确保:
没有精度丢失
不会输出小数数字
指数(或后缀)尽可能大。
除非数量是负数,否则将省略正负号。
例如:
1.5 将会被序列化成 “1500m”
1.5Gi 将会被序列化成 “1536Mi”
请注意,数量永远不会 在内部以浮点数表示。这是本设计的重中之重。
只要它们格式正确,非规范值仍将解析,但将以其规范形式重新输出。(所以应该总是使用规范形式,否则不要执行 diff 比较。)
这种格式旨在使得很难在不撰写某种特殊处理代码的情况下使用这些数字,进而希望实现者也使用定点实现。
5.1.10 - ResourceFieldSelector
ResourceFieldSelector 表示容器资源(CPU,内存)及其输出格式。
import "k8s.io/api/core/v1"
ResourceFieldSelector 表示容器资源(CPU,内存)及其输出格式。
resource (string), 必选
必选:选择的资源
containerName (string)
容器名称:对卷必选,对环境变量可选
divisor (Quantity )
指定所曝光资源的输出格式,默认值为“1”
5.1.11 - TypedLocalObjectReference
TypedLocalObjectReference 包含足够的信息,可以让你在同一个名称空间中定位指定类型的引用对象。
import "k8s.io/api/core/v1"
TypedLocalObjectReference 包含足够的信息,可以让你在同一个名称空间中定位特定类型的引用对象。
6 - Kubernetes 问题和安全
6.1 - Kubernetes 问题追踪
要报告安全问题,请遵循
Kubernetes 安全问题公开流程 。
使用 GitHub Issues
跟踪 Kubernetes 编码工作和公开问题。
与安全性相关的公告请发送到
kubernetes-security-announce@googlegroups.com
邮件列表。
6.2 - Kubernetes 安全和信息披露
本页面介绍 Kubernetes 安全和信息披露相关的内容。
安全公告
加入 kubernetes-security-announce 组,以获取关于安全性和主要 API 公告的电子邮件。
报告一个漏洞
我们非常感谢向 Kubernetes 开源社区报告漏洞的安全研究人员和用户。
所有的报告都由社区志愿者进行彻底调查。
如需报告,请连同安全细节以及预期的所有 Kubernetes bug 报告
详细信息电子邮件到security@kubernetes.io 列表。
你还可以通过电子邮件向私有 security@kubernetes.io
列表发送电子邮件,邮件中应该包含
所有 Kubernetes 错误报告
所需的详细信息。
你可以使用安全响应委员会成员 的
GPG 密钥加密你的发往邮件列表的邮件。揭示问题时不需要使用 GPG 来加密。
我应该在什么时候报告漏洞?
你认为在 Kubernetes 中发现了一个潜在的安全漏洞
你不确定漏洞如何影响 Kubernetes
你认为你在 Kubernetes 依赖的另一个项目中发现了一个漏洞
对于具有漏洞报告和披露流程的项目,请直接在该项目处报告
我什么时候不应该报告漏洞?
你需要帮助调整 Kubernetes 组件的安全性
你需要帮助应用与安全相关的更新
你的问题与安全无关
安全漏洞响应
每个报告在 3 个工作日内由安全响应委员会成员确认和分析。这将启动安全发布过程 。
与安全响应委员会共享的任何漏洞信息都保留在 Kubernetes 项目中,除非有必要修复该问题,否则不会传播到其他项目。
随着安全问题从分类、识别修复、发布计划等方面的进展,我们将不断更新报告。
公开披露时间
公开披露日期由 Kubernetes 安全响应委员会和 bug 提交者协商。
我们倾向于在能够为用户提供缓解措施之后尽快完全披露该 bug。
当 bug 或其修复还没有被完全理解,解决方案没有经过良好的测试,或者为了处理供应商协调问题时,延迟披露是合理的。
信息披露的时间范围从即时(尤其是已经公开的)到几周。作为一个基本的约定,我们希望报告日期到披露日期的间隔是 7 天。在设置披露日期时,Kubernetes 产品安全团队拥有最终决定权。
7 - 节点参考信息
7.1 - 关于 dockershim 移除和使用兼容 CRI 运行时的外部文章
这是有关以下内容的文章列表:
Kubernetes 弃用和删除 dockershim
使用兼容 CRI 的容器运行时
首要来源
次要来源
8 - 安装工具
8.1 - Kubeadm
Kubeadm 是一个提供了 kubeadm init
和 kubeadm join
的工具,
作为创建 Kubernetes 集群的 “快捷途径” 的最佳实践。
kubeadm 通过执行必要的操作来启动和运行最小可用集群。
按照设计,它只关注启动引导,而非配置机器。同样的,
安装各种 “锦上添花” 的扩展,例如 Kubernetes Dashboard、
监控方案、以及特定云平台的扩展,都不在讨论范围内。
相反,我们希望在 kubeadm 之上构建更高级别以及更加合规的工具,
理想情况下,使用 kubeadm 作为所有部署工作的基准将会更加易于创建一致性集群。
如何安装
要安装 kubeadm, 请查阅
安装指南 .
接下来
8.1.1 - 创建 Kubeadm
8.1.1.1 -
摘要
┌──────────────────────────────────────────────────────────┐
│ KUBEADM │
│ 轻松创建一个安全的 Kubernetes 集群 │
│ │
│ 给我们反馈意见的地址: │
│ https://github.com/kubernetes/kubeadm/issues │
└──────────────────────────────────────────────────────────┘
用途示例:
创建一个有两台机器的集群,包含一个主节点(用来控制集群),和一个工作节点(运行您的工作负载,像 Pod 和 Deployment)。
┌──────────────────────────────────────────────────────────┐
│ 在第一台机器上: │
├──────────────────────────────────────────────────────────┤
│ control-plane# kubeadm init │
└──────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────┐
│ 在第二台机器上: │
├──────────────────────────────────────────────────────────┤
│ worker# kubeadm join <arguments-returned-from-init>│
└──────────────────────────────────────────────────────────┘
您可以重复第二步,向集群添加更多机器。
选项
-h, --help
kubeadm 操作的帮助信息
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.2 -
概要
kubeadm 实验子命令
选项
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机的根文件系统的路径。
8.1.1.3 -
概要
与处理 kubernetes 证书相关的命令
选项
继承于父命令的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
8.1.1.4 -
概要
该命令将打印出可以与 "init" 命令一起使用的安全的随机生成的证书密钥。
你也可以使用 kubeadm init --upload-certs
而无需指定证书密钥;
命令将为你生成并打印一个证书密钥。
kubeadm certs certificate-key [flags]
选项
-h, --help
certificate-key 操作的帮助命令
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.5 -
概要
检查 kubeadm 管理的本地 PKI 中证书的到期时间。
kubeadm certs check-expiration [flags]
选项
--cert-dir string 默认值: "/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件的路径
-h, --help
check-expiration 的帮助命令
继承于父命令的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
8.1.1.6 -
为运行控制平面所需的所有证书生成密钥和证书签名请求(CSR)。该命令会生成部分 kubeconfig 文件,
其中 "users > user > client-key-data" 字段包含私钥数据,并为每个 kubeconfig
文件创建一个随附的 ".csr" 文件。
此命令设计用于
Kubeadm 外部 CA 模式 。
它生成你可以提交给外部证书颁发机构进行签名的 CSR。
应使用 ".crt" 作为文件扩展名将 PEM 编码的签名证书与密钥文件一起保存。
或者,对于 kubeconfig 文件,PEM 编码的签名证书应使用 base64 编码,
并添加到 "users > user > client-certificate-data" 字段。
kubeadm certs generate-csr [flags]
示例
# 以下命令将为所有控制平面证书和 kubeconfig 文件生成密钥和 CSR :
kubeadm certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki
选项
--cert-dir string
保存证书的路径
--config string
kubeadm 配置文件的路径。
-h, --help
generate-csr 命令的帮助
--kubeconfig-dir string 默认值:"/etc/kubernetes"
保存 kubeconfig 文件的路径。
继承于父命令的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
8.1.1.7 -
概要
此命令并非设计用来单独运行。请参阅可用子命令列表。
kubeadm certs renew [flags]
选项
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.8 -
概要
续订 kubeconfig 文件中嵌入的证书,供管理员 和 kubeadm 自身使用。
无论证书的到期日期如何,续订都是无条件进行的;SAN 等额外属性将基于现有文件/证书,因此无需重新提供它们。
默认情况下,续订会尝试使用由 kubeadm 管理的本地 PKI 中的证书机构;作为替代方案,
也可以使用 K8s 证书 API 进行证书续订,或者(作为最后一种选择)生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防证书文件在其他地方使用。
kubeadm certs renew admin.conf [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
CSR 和私钥的输出路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
admin.conf 子操作的帮助命令
--kubeconfig string Default: "/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.9 -
概要
续订运行控制平面所需的所有已知证书。续订是无条件进行的,与到期日期无关。续订也可以单独运行以进行更多控制。
kubeadm certs renew all [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
输出 CSR 和私钥的路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
all 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.10 -
概要
续订 apiserver 用于访问 etcd 的证书。
无论证书的到期日期如何,续订都会无条件地进行;SAN 等额外属性将基于现有文件/证书,因此无需重新提供它们。
默认情况下,续订尝试使用在 kubeadm 所管理的本地 PKI 中的证书颁发机构;作为替代方案,
可以使用 K8s 证书 API 进行证书更新,或者作为最后一个选择来生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防文件在其他地方使用。
kubeadm certs renew apiserver-etcd-client [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
输出 CSR 和私钥的路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
apiserver-etcd-client 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.11 -
概要
续订 apiserver 用于连接 kubelet 的证书。
无论证书的到期日期如何,续订都会无条件地进行;SAN 等额外属性将基于现有文件/证书,因此无需重新提供它们。
默认情况下,续订尝试使用位于 kubeadm 所管理的本地 PKI 中的证书颁发机构;作为替代方案,
也可能调用 K8s 证书 API 进行证书更新;亦或者,作为最后一个选择,生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防文件在其他地方使用。
kubeadm certs renew apiserver-kubelet-client [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
输出 CSR 和私钥的路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
apiserver-kubelet-client 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.12 -
概要
续订用于提供 Kubernetes API 的证书。
无论证书的到期日期如何,续订都会无条件地进行;SAN 等额外属性将基于现有文件/证书,因此无需重新提供它们。
默认情况下,续订尝试在 kubeadm 管理的本地 PKI 中使用证书颁发机构;作为替代方案,
可以使用 K8s 证书 API 进行证书更新,或者作为最后一个选择来生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防文件在其他地方使用。
kubeadm certs renew apiserver [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
CSR 和私钥的输出路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
apiserver 子操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.13 -
概要
续订 kubeconfig 文件中嵌入的证书,以供控制器管理器(Controller Manager)使用。
续订无条件地进行,与证书的到期日期无关;SAN 等额外属性将基于现有的文件/证书,因此无需重新提供它们。
默认情况下,续订会尝试使用 kubeadm 管理的本地 PKI 中的证书颁发机构;作为替代方案,
可以使用 K8s 证书 API 进行证书续订;亦或者,作为最后一种选择,生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防文件在其他地方使用。
kubeadm alpha renew controller-manager.conf [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
CSR 和私钥的输出路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
controller-manager.conf 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.14 -
概要
续订存活态探针的证书,用于对 etcd 执行健康检查。
无论证书的到期日期如何,续订都是无条件进行的;SAN 等额外属性将基于现有文件/证书,因此无需重新提供它们。
默认情况下,续订会尝试使用由 kubeadm 管理的本地 PKI 中的证书机构;作为替代方案,
也可以使用 K8s certificate API 进行证书续订,或者(作为最后一种选择)生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防证书文件在其他地方使用。
kubeadm certs renew etcd-healthcheck-client [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
CSR 和私钥的输出路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
etcd-healthcheck-client 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.15 -
概要
续订 etcd 节点间用来相互通信的证书。
无论证书的到期日期如何,续订都是无条件进行的;SAN 等额外属性将基于现有文件/证书,因此无需重新提供它们。
默认情况下,续订会尝试使用由 kubeadm 管理的本地 PKI 中的证书机构;
作为替代方案,也可以使用 K8s certificate API 进行证书续订,或者(作为最后一种选择)生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防证书文件在其他地方使用。
kubeadm certs renew etcd-peer [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
CSR 和私钥的输出路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
etcd-peer 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.16 -
概要
续订用于提供 etcd 服务的证书。
续订无条件地进行,与证书的到期日期无关;SAN 等额外属性将基于现有的文件/证书,因此无需重新提供它们。
默认情况下,续订会尝试在 kubeadm 管理的本地 PKI 中使用证书颁发机构;作为替代方案,
可以使用 K8s 证书 API 进行证书续订,或者作为最后一种选择来生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防文件在其他地方使用。
kubeadm certs renew etcd-server [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
CSR 和私钥的输出路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
etcd-server 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.17 -
概要
为前端代理客户端续订证书。
无论证书的到期日期如何,续订都会无条件地进行;SAN 等额外属性将基于现有文件/证书,因此无需重新提供它们。
默认情况下,续订尝试使用位于 kubeadm 所管理的本地 PKI 中的证书颁发机构;作为替代方案,
也可以使用 K8s 证书 API 进行证书续订;亦或者,作为最后一种方案,生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防文件在其他地方使用。
kubeadm certs renew front-proxy-client [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
输出 CSR 和私钥的路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
front-proxy-client 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.18 -
概要
续订 kubeconfig 文件中嵌入的证书,以供调度管理器使用。
续订无条件地进行,与证书的到期日期无关;SAN 等额外属性将基于现有的文件/证书,因此无需重新提供它们。
默认情况下,续订会尝试使用在 kubeadm 所管理的本地 PKI 中的证书颁发机构;作为替代方案,
也可以使用 K8s 证书 API 进行证书续订;亦或者,作为最后一种选择,生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防文件在其他地方使用。
kubeadm certs renew scheduler.conf [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
CSR 和私钥的输出路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
scheduler.conf 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.19 -
概要
为指定的 shell(bash 或 zsh)输出 shell 自动补全代码。
必须激活 shell 代码以提供交互式 kubeadm 命令补全。这可以通过加载 .bash_profile 文件完成。
注意: 此功能依赖于 bash-completion
框架。
在 Mac 上使用 homebrew 安装:
brew install bash-completion
安装后,必须激活 bash_completion。这可以通过在 .bash_profile 文件中添加下面的命令行来完成
source $(brew --prefix)/etc/bash_completion
如果在 Linux 上没有安装 bash-completion,请通过您的发行版的包管理器安装 bash-completion
软件包。
zsh 用户注意事项:[1] zsh 自动补全仅在 >=v5.2 及以上版本中支持。
kubeadm completion SHELL [flags]
示例
# 在 Mac 上使用 homebrew 安装 bash completion
brew install bash-completion
printf "\n# Bash completion support\nsource $(brew --prefix)/etc/bash_completion\n" >> $HOME/.bash_profile
source $HOME/.bash_profile
# 将 bash 版本的 kubeadm 自动补全代码加载到当前 shell 中
source <(kubeadm completion bash)
# 将 bash 自动补全完成代码写入文件并且从 .bash_profile 文件加载它
printf "\n# Kubeadm shell completion\nsource '$HOME/.kube/kubeadm_completion.bash.inc'\n" >> $HOME/.bash_profile
source $HOME/.bash_profile
# 将 zsh 版本的 kubeadm 自动补全代码加载到当前 shell 中
source <(kubeadm completion zsh)
选项
-h, --help
completion 操作的帮助命令
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.20 -
概要
kube-system 命名空间里有一个名为 "kubeadm-config" 的 ConfigMap,kubeadm 用它来存储有关集群的内部配置。
kubeadm CLI v1.8.0+ 通过一个配置自动创建该 ConfigMap,这个配置是和 'kubeadm init' 共用的。
但是您如果使用 kubeadm v1.7.x 或更低的版本初始化集群,那么必须使用 'config upload' 命令创建该 ConfigMap。
这是必要的操作,目的是使 'kubeadm upgrade' 能够正确地配置升级后的集群。
kubeadm config [flags]
选项
-h, --help
config 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 kubeconfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 kubeconfig 文件
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.21 -
概要
与 kubeadm 使用的容器镜像交互。
kubeadm config images [flags]
选项
从父命令继承的选项
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 kubeconfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 kubeconfig 文件。
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.22 -
概要
打印 kubeadm 要使用的镜像列表。配置文件用于自定义任何镜像或镜像存储库。
kubeadm config images list [flags]
选项
--allow-missing-template-keys 默认值:true
如果设置为 true,则在模板中缺少字段或哈希表的键时忽略模板中的任何错误。
仅适用于 golang 和 jsonpath 输出格式。
-o, --experimental-output string 默认值:"text"
输出格式:text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file 其中之一
--config string
kubeadm 配置文件的路径。
--feature-gates string
一组键值对(key=value),用于描述各种特征。选项是:
Auditing=true|false (ALPHA - 默认=false)
CoreDNS=true|false (默认=true)
DynamicKubeletConfig=true|false (BETA - 默认=false)
-h, --help
list 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择要从中拉取控制平面镜像的容器仓库
--kubernetes-version string 默认值:"stable-1"
为控制平面选择一个特定的 Kubernetes 版本
从父命令继承的选项
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 kubeconfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 kubeconfig 文件。
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.23 -
概要
拉取 kubeadm 使用的镜像。
kubeadm config images pull [flags]
选项
--config string
kubeadm 配置文件的路径。
--cri-socket string
要连接的 CRI 套接字的路径。如果为空,则 kubeadm 将尝试自动检测此值;仅当安装了多个 CRI 或具有非标准 CRI 插槽时,才使用此选项。
--feature-gates string
一系列键值对(key=value),用于描述各种特征。可选项是: IPv6DualStack=true|false (ALPHA - 默认值=false)
-h, --help
pull 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择用于拉取控制平面镜像的容器仓库
--kubernetes-version string 默认值:"stable-1"
为控制平面选择一个特定的 Kubernetes 版本。
从父命令继承的选项
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 kubeconfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 kubeconfig 文件。
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.24 -
概要
此命令允许您在 CLI 工具中将本地旧版本的配置对象转换为最新支持的版本,而无需变更集群中的任何内容。在此版本的 kubeadm 中,支持以下 API 版本:
因此,无论您在此处传递 --old-config 参数的版本是什么,当写入到 stdout 或 --new-config (如果已指定)时,
都会读取、反序列化、默认、转换、验证和重新序列化 API 对象。
换句话说,如果您将此文件传递给 "kubeadm init",则该命令的输出就是 kubeadm 实际上在内部读取的内容。
kubeadm config migrate [flags]
选项
-h, --help
migrate 操作的帮助信息
--new-config string
使用新的 API 版本生成的 kubeadm 配置文件的路径。这个路径是可选的。如果没有指定,输出将被写到 stdout。
--old-config string
使用旧 API 版本且应转换的 kubeadm 配置文件的路径。此参数是必需的。
从父命令继承的选项
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 kubeconfig 文件。如果未设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 kubeconfig 文件。
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.25 -
打印配置
概要
此命令打印子命令所提供的配置信息。
相关细节可参阅 https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2
kubeadm config print [flags]
选项
从父命令继承而来的选项
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如此标志未设置,将在一组标准位置中搜索现有的kubeconfig 文件。
--rootfs string
[试验性] 指向“真实”宿主根文件系统的路径。
8.1.1.26 -
概要
此命令打印对象,例如用于 'kubeadm init' 的默认 init 配置对象。
请注意,Bootstrap Token 字段之类的敏感值已替换为 {"abcdef.0123456789abcdef" "" "nil" <nil> [] []} 之类的占位符值以通过验证,但不执行创建令牌的实际计算。
kubeadm config print init-defaults [flags]
选项
--component-configs stringSlice
组件配置 API 对象的逗号分隔列表,打印其默认值。可用值:[KubeProxyConfiguration KubeletConfiguration]。如果未设置此参数,则不会打印任何组件配置。
-h, --help
init-defaults 操作的帮助命令
从父命令继承的选项
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.27 -
概要
此命令打印对象,例如用于 'kubeadm join' 的默认 join 配置对象。
请注意,诸如启动引导令牌字段之类的敏感值已替换为 {"abcdef.0123456789abcdef" "" "nil" <nil> [] []}
之类的占位符值以通过验证,但不执行创建令牌的实际计算。
kubeadm config print join-defaults [flags]
选项
--component-configs stringSlice
组件配置 API 对象的逗号分隔列表,打印其默认值。可用值:[KubeProxyConfiguration KubeletConfiguration]。如果未设置此参数,则不会打印任何组件配置。
-h, --help
join-defaults 操作的帮助命令
从父命令继承的选项
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.28 -
概要
运行此命令来搭建 Kubernetes 控制平面节点。
"init" 命令执行以下阶段:
preflight Run pre-flight checks
certs Certificate generation
/ca Generate the self-signed Kubernetes CA to provision identities for other Kubernetes components
/apiserver Generate the certificate for serving the Kubernetes API
/apiserver-kubelet-client Generate the certificate for the API server to connect to kubelet
/front-proxy-ca Generate the self-signed CA to provision identities for front proxy
/front-proxy-client Generate the certificate for the front proxy client
/etcd-ca Generate the self-signed CA to provision identities for etcd
/etcd-server Generate the certificate for serving etcd
/etcd-peer Generate the certificate for etcd nodes to communicate with each other
/etcd-healthcheck-client Generate the certificate for liveness probes to healthcheck etcd
/apiserver-etcd-client Generate the certificate the apiserver uses to access etcd
/sa Generate a private key for signing service account tokens along with its public key
kubeconfig Generate all kubeconfig files necessary to establish the control plane and the admin kubeconfig file
/admin Generate a kubeconfig file for the admin to use and for kubeadm itself
/kubelet Generate a kubeconfig file for the kubelet to use *only* for cluster bootstrapping purposes
/controller-manager Generate a kubeconfig file for the controller manager to use
/scheduler Generate a kubeconfig file for the scheduler to use
kubelet-start Write kubelet settings and (re)start the kubelet
control-plane Generate all static Pod manifest files necessary to establish the control plane
/apiserver Generates the kube-apiserver static Pod manifest
/controller-manager Generates the kube-controller-manager static Pod manifest
/scheduler Generates the kube-scheduler static Pod manifest
etcd Generate static Pod manifest file for local etcd
/local Generate the static Pod manifest file for a local, single-node local etcd instance
upload-config Upload the kubeadm and kubelet configuration to a ConfigMap
/kubeadm Upload the kubeadm ClusterConfiguration to a ConfigMap
/kubelet Upload the kubelet component config to a ConfigMap
upload-certs Upload certificates to kubeadm-certs
mark-control-plane Mark a node as a control-plane
bootstrap-token Generates bootstrap tokens used to join a node to a cluster
kubelet-finalize Updates settings relevant to the kubelet after TLS bootstrap
/experimental-cert-rotation Enable kubelet client certificate rotation
addon Install required addons for passing Conformance tests
/coredns Install the CoreDNS addon to a Kubernetes cluster
/kube-proxy Install the kube-proxy addon to a Kubernetes cluster
kubeadm init [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则使用默认网络接口。
--apiserver-bind-port int32 默认值:6443
API 服务器绑定的端口。
--apiserver-cert-extra-sans stringSlice
用于 API Server 服务证书的可选附加主题备用名称(SAN)。可以是 IP 地址和 DNS 名称。
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--certificate-key string
用于加密 kubeadm-certs Secret 中的控制平面证书的密钥。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
--cri-socket string
要连接的 CRI 套接字的路径。如果为空,则 kubeadm 将尝试自动检测此值;仅当安装了多个 CRI 或具有非标准 CRI 插槽时,才使用此选项。
--dry-run
不要应用任何更改;只是输出将要执行的操作。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
--feature-gates string
一组用来描述各种功能特性的键值(key=value)对。选项是: IPv6DualStack=true|false (ALPHA - default=false)
-h, --help
init 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查列表;例如:'IsPrivilegedUser,Swap'。取值为 'all' 时将忽略检查中的所有错误。
--image-repository string 默认值:"k8s.gcr.io"
选择用于拉取控制平面镜像的容器仓库
--kubernetes-version string 默认值:"stable-1"
为控制平面选择一个特定的 Kubernetes 版本。
--node-name string
指定节点的名称。
--pod-network-cidr string
指明 pod 网络可以使用的 IP 地址段。如果设置了这个参数,控制平面将会为每一个节点自动分配 CIDRs。
--service-cidr string 默认值:"10.96.0.0/12"
为服务的虚拟 IP 地址另外指定 IP 地址段
--service-dns-domain string 默认值:"cluster.local"
为服务另外指定域名,例如:"myorg.internal"。
--skip-certificate-key-print
不要打印用于加密控制平面证书的密钥。
--skip-phases stringSlice
要跳过的阶段列表
--skip-token-print
跳过打印 'kubeadm init' 生成的默认引导令牌。
--token string
这个令牌用于建立控制平面节点与工作节点间的双向通信。格式为 [a-z0-9]{6}\.[a-z0-9]{16} - 示例:abcdef.0123456789abcdef
--token-ttl duration 默认值:24h0m0s
令牌被自动删除之前的持续时间(例如 1 s,2 m,3 h)。如果设置为 '0',则令牌将永不过期
--upload-certs
将控制平面证书上传到 kubeadm-certs Secret。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.29 -
概要
使用此命令可以调用 init 工作流程的单个阶段
选项
继承于父命令的选择项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.30 -
概要
此命令并非设计用来单独运行。请参阅可用子命令列表。
kubeadm init phase addon [flags]
选项
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.31 -
概要
安装所有插件(addon)
kubeadm init phase addon all [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则将使用默认网络接口。
--apiserver-bind-port int32 默认值:6443
API 服务器绑定的端口。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
--feature-gates string
一组键值对(key=value),描述了各种特征。选项包括: IPv6DualStack=true|false (ALPHA - 默认值=false)
-h, --help
--image-repository string 默认值:"k8s.gcr.io"
选择用于拉取控制平面镜像的容器仓库
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
--pod-network-cidr string
指定 Pod 网络的 IP 地址范围。如果已设置,控制平面将自动为每个节点分配 CIDR。
--service-cidr string 默认值:"10.96.0.0/12"
为服务 VIP 使用 IP 地址的其他范围。
--service-dns-domain string 默认值:"cluster.local"
为服务使用其他域名,例如 "myorg.internal"。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.32 -
概要
通过 API 服务器安装 CoreDNS 附加组件。请注意,即使 DNS 服务器已部署,在安装 CNI 之前 DNS 服务器不会被调度执行。
kubeadm init phase addon coredns [flags]
选项
--config string
kubeadm 配置文件的路径。
--feature-gates string
一组用来描述各种功能特性的键值(key=value)对。选项是: IPv6DualStack=true|false (ALPHA - 默认值=false)
-h, --help
coredns 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择用于拉取控制平面镜像的容器仓库
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
--service-cidr string 默认值:"10.96.0.0/12"
为服务 VIP 选择 IP 地址范围。
--service-dns-domain string 默认值:"cluster.local"
服务使用其它的域名,例如:"myorg.internal"。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.33 -
概要
通过 API 服务器安装 kube-proxy 附加组件。
kubeadm init phase addon kube-proxy [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则将使用默认网络接口。
--apiserver-bind-port int32 默认值: 6443
API 服务器绑定的端口。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
kube-proxy 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择用于拉取控制平面镜像的容器仓库
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
--pod-network-cidr string
指定 Pod 网络的 IP 地址范围。如果已设置,控制平面将自动为每个节点分配 CIDR。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.34 -
概要
启动引导令牌(bootstrap token)用于在即将加入集群的节点和控制平面节点之间建立双向信任。
该命令使启动引导令牌(bootstrap token)所需的所有配置生效,然后创建初始令牌。
kubeadm init phase bootstrap-token [flags]
示例
# 进行所有引导令牌配置,并创建一个初始令牌,功能上与 kubeadm init 生成的令牌等效。
kubeadm init phase bootstrap-token
选项
--config string
kubeadm 配置文件的路径。
-h, --help
bootstrap-token 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 kubeconfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 kubeconfig 文件。
--skip-token-print
跳过打印 'kubeadm init' 生成的默认引导令牌。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.35 -
概要
此命令并非设计用来单独运行。请参阅可用子命令列表。
kubeadm init phase certs [flags]
选项
从父指令中继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.36 -
概要
生成所有证书
kubeadm init phase certs all [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,将使用默认网络接口。
--apiserver-cert-extra-sans stringSlice
用于 API 服务器服务证书的可选额外替代名称(SAN)。可以同时使用 IP 地址和 DNS 名称。
--cert-dir string 默认值:"/etc/kubernetes/pki"
证书的存储路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
all 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
--service-cidr string 默认值:"10.96.0.0/12"
VIP 服务使用其它的 IP 地址范围。
--service-dns-domain string 默认值:"cluster.local"
服务使用其它的域名,例如:"myorg.internal"。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.37 -
概要
生成 apiserver 用于访问 etcd 的证书,并将其保存到 apiserver-etcd-client.cert 和 apiserver-etcd-client.key 文件中。
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 Alpha 功能。
kubeadm init phase certs apiserver-etcd-client [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
证书的存储路径。
--config string
kubeadm 配置文件的路径。
-h, --help
apiserver-etcd-client 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.38 -
概要
生成供 API 服务器连接 kubelet 的证书,并将其保存到 apiserver-kubelet-client.cert 和 apiserver-kubelet-client.key 文件中。
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 Alpha 功能。
kubeadm init phase certs apiserver-kubelet-client [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件路径。
-h, --help
apiserver-kubelet-client 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 指向宿主机上的 '实际' 根文件系统的路径。
8.1.1.39 -
概要
生成用于服务 Kubernetes API 的证书,并将其保存到 apiserver.cert 和 apiserver.key 文件中。
默认 SAN 是 kubernetes、kubernetes.default、kubernetes.default.svc、kubernetes.default.svc.cluster.local、10.96.0.1、127.0.0.1。
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 Alpha 功能。
kubeadm init phase certs apiserver [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则使用默认的网络接口。
--apiserver-cert-extra-sans stringSlice
用于 API Server 服务证书的可选附加主体备用名称(SAN)。可以是 IP 地址和 DNS 名称。
--cert-dir string 默认值:"/etc/kubernetes/pki"
证书的存储路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
apiserver 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
--service-cidr string 默认值:"10.96.0.0/12"
指定服务 VIP 可使用的其他 IP 地址段。
--service-dns-domain string 默认值:"cluster.local"
为服务使用其他域名,例如 "myorg.internal"。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.40 -
概要
生成自签名的 Kubernetes CA 以提供其他 Kubernetes 组件的身份,并将其保存到 ca.cert 和 ca.key 文件中。
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 Alpha 功能。
kubeadm init phase certs ca [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
证书的存储路径。
--config string
kubeadm 配置文件的路径。
-h, --help
ca 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.41 -
概要
生成用于为 etcd 设置身份的自签名 CA,并将其保存到 etcd/ca.cert 和 etcd/ca.key 文件中。
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 Alpha 功能。
kubeadm init phase certs etcd-ca [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
证书的存储路径。
--config string
kubeadm 配置文件的路径。
-h, --help
etcd-ca 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.42 -
概要
生成用于 etcd 健康检查的活跃性探针的证书,并将其保存到 healthcheck-client.cert 和 etcd/healthcheck-client.key 文件中。
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 alpha 功能。
kubeadm init phase certs etcd-healthcheck-client [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
证书存储的路径。
--config string
kubeadm 配置文件的路径。
-h, --help
etcd-healthcheck-client 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.43 -
概要
生成 etcd 节点相互通信的证书,并将其保存到 etcd/peer.cert 和 etcd/peer.key 文件中。
默认 SAN 为 localhost、127.0.0.1、127.0.0.1、:: 1
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 alpha 功能。
kubeadm init phase certs etcd-peer [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
-h, --help
etcd-peer 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.44 -
概要
生成用于提供 etcd 服务的证书,并将其保存到 etcd/server.cert 和 etcd/server.key 文件中。
默认 SAN 为 localhost、127.0.0.1、127.0.0.1、:: 1
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 alpha 功能。
kubeadm init phase certs etcd-server [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
-h, --help
etcd-server 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.45 -
概要
生成自签名 CA 来提供前端代理的身份,并将其保存到 front-proxy-ca.cert 和 front-proxy-ca.key 文件中。
如果两个文件都已存在,kubeadm 将跳过生成步骤并将使用现有文件。
Alpha 免责声明:此命令目前是 alpha 阶段。
kubeadm init phase certs front-proxy-ca [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
-h, --help
front-proxy-ca 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.46 -
概要
为前端代理客户端生成证书,并将其保存到 front-proxy-client.cert 和 front-proxy-client.key 文件中。
如果两个文件都已存在,kubeadm 将跳过生成步骤并将使用现有文件。
Alpha 免责声明:此命令目前是 alpha 阶段。
kubeadm init phase certs front-proxy-client [flags]
选项
--cert-dir string 默认:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
-h, --help
front-proxy-client 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.47 -
概要
生成用于签名 service account 令牌的私钥及其公钥,并将其保存到 sa.key 和 sa.pub 文件中。如果两个文件都已存在,则 kubeadm 会跳过生成步骤,而将使用现有文件。
Alpha 免责声明:此命令当前为 alpha 阶段。
kubeadm init phase certs sa [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
-h, --help
sa 操作的帮助命令
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.48 -
概要
此命令并非设计用来单独运行。请参阅可用子命令列表。
kubeadm init phase control-plane [flags]
选项
-h, --help
control-plane 操作的帮助命令
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.49 -
概要
生成所有的静态 Pod 清单文件
kubeadm init phase control-plane all [flags]
示例
# 为控制平面组件生成静态 Pod 清单文件,其功能等效于 kubeadm init 生成的文件。
kubeadm init phase control-plane all
# 使用从某配置文件中读取的选项为生成静态 Pod 清单文件。
kubeadm init phase control-plane all --config config.yaml
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,将使用默认的网络接口。
--apiserver-bind-port int32 默认值:6443
API 服务器要绑定的端口。
--apiserver-extra-args mapStringString
形式为 <flagname>=<value> 的一组额外参数,用来传递给 API 服务器,
或者覆盖其默认配置值
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面选择一个稳定的 IP 地址或者 DNS 名称。
--controller-manager-extra-args mapStringString
一组形式为 <flagname>=<value> 的额外参数,用来传递给控制管理器(Controller Manager)
或覆盖其默认设置值
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录。
例如,"kube-apiserver0+merge.yaml" 或者 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,分别与 kubectl
所支持的 patch 格式相匹配。默认的 "patchtype" 是 "strategic"。
"extension" 必须是 "json" 或 "yaml"。
"suffix" 是一个可选的字符串,用来确定按字母顺序排序时首先应用哪些 patch。
--feature-gates string
一组用来描述各种特性门控的键值(key=value)对。选项是:
IPv6DualStack=true|false (ALPHA - 默认=false)
PublicKeysECDSA=true|false (ALPHA - 默认=false)
-h, --help
all 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择用于拉取控制平面镜像的容器仓库
--kubernetes-version string 默认值:"stable-1"
为控制平面选择指定的 Kubernetes 版本。
--pod-network-cidr string
指定 Pod 网络的 IP 地址范围。如果设置了此标志,控制平面将自动地为每个节点分配 CIDR。
--scheduler-extra-args mapStringString
一组形式为 <flagname>=<value> 的额外参数,用来传递给调度器(Scheduler)
或覆盖其默认设置值
传递给调度器(scheduler)一组额外的参数或者以 <flagname>=<value> 形式覆盖其默认值。
--service-cidr string 默认值:"10.96.0.0/12"
为服务 VIP 选择 IP 地址范围。
从父指令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机的根文件系统的路径。
8.1.1.50 -
概要
生成 kube-apiserver 静态 Pod 清单
kubeadm init phase control-plane apiserver [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,将使用默认网络接口。
--apiserver-bind-port int32 默认值: 6443
要绑定到 API 服务器的端口。
--apiserver-extra-args mapStringString
一组 <flagname>=<value> 形式的额外参数,用来传递给 API 服务器
或者覆盖其默认参数配置
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
包含名为 "target[suffix][+patchtype].extension" 的文件的目录。
例如,"kube-apiserver0+merge.yaml" 或者 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,分别与 kubectl
所支持的 patch 格式相匹配。默认的 "patchtype" 是 "strategic"。
"extension" 必须是 "json" 或 "yaml"。
"suffix" 是一个可选的字符串,用来确定按字母顺序排序时首先应用哪些 patch。
--feature-gates string
一组键值对,用于描述各种功能特性的特性门控。选项是:
IPv6DualStack=true|false (ALPHA - 默认=false)
PublicKeysECDSA=true|false (ALPHA - 默认=false)
-h, --help
apiserver 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择要从中拉取控制平面镜像的容器仓库
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本
--service-cidr string 默认值:"10.96.0.0/12"
指定服务 VIP 使用 IP 地址的其他范围。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统路径。
8.1.1.51 -
概要
生成 kube-controller-manager 静态 Pod 清单
kubeadm init phase control-plane controller-manager [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--controller-manager-extra-args mapStringString
一组 <flagname>=< 形式的额外参数,传递给控制器管理器(Controller Manager)
或者覆盖其默认配置值
包含名为 "target[suffix][+patchtype].extension" 的文件的目录。
例如,"kube-apiserver0+merge.yaml" 或者 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,分别与 kubectl
所支持的 patch 格式相匹配。默认的 "patchtype" 是 "strategic"。
"extension" 必须是 "json" 或 "yaml"。
"suffix" 是一个可选的字符串,用来确定按字母顺序排序时首先应用哪些 patch。
-h, --help
controller-manager 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择要从中拉取控制平面镜像的容器仓库
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
--pod-network-cidr string
指定 Pod 网络的 IP 地址范围。如果设置,控制平面将自动为每个节点分配 CIDR。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.52 -
概要
生成 kube-scheduler 静态 Pod 清单
kubeadm init phase control-plane scheduler [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录。
例如,"kube-apiserver0+merge.yaml" 或者 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,分别与 kubectl
所支持的 patch 格式相匹配。默认的 "patchtype" 是 "strategic"。
"extension" 必须是 "json" 或 "yaml"。
"suffix" 是一个可选的字符串,用来确定按字母顺序排序时首先应用哪些 patch。
-h, --help
scheduler 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择要从中拉取控制平面镜像的容器仓库
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
--scheduler-extra-args mapStringString
一组 <flagname>=<value> 形式的额外参数,用来传递给调度器
或者覆盖其默认参数配置
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.53 -
概要
此命令并非设计用来单独运行。请参阅可用子命令列表。
kubeadm init phase etcd [flags]
选项
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.54 -
概要
为本地单节点 etcd 实例生成静态 Pod 清单文件
kubeadm init phase etcd local [flags]
示例
# 为 etcd 生成静态 Pod 清单文件,其功能等效于 kubeadm init 生成的文件。
kubeadm init phase etcd local
# 使用从配置文件读取的选项为 etcd 生成静态 Pod 清单文件。
kubeadm init phase etcd local --config config.yaml
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
-h, --help
local 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择要从中拉取控制平面镜像的容器仓库
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.55 -
概要
此命令并非设计用来单独运行。请阅读可用子命令列表。
kubeadm init phase kubeconfig [flags]
选项
-h, --help
kubeconfig 操作的帮助命令
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.56 -
概要
为管理员和 kubeadm 本身生成 kubeconfig 文件,并将其保存到 admin.conf 文件中。
kubeadm init phase kubeconfig admin [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则使用默认的网络接口。
--apiserver-bind-port int32 默认值:6443
要绑定到 API 服务器的端口。
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
admin 操作的帮助命令
--kubeconfig-dir string 默认值:"/etc/kubernetes"
kubeconfig 文件的保存路径。
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.57 -
概要
生成所有 kubeconfig 文件
kubeadm init phase kubeconfig all [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果没有设置,将使用默认的网络接口。
--apiserver-bind-port int32 默认值:6443
要绑定到 API 服务器的端口。
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
all 操作的帮助命令
--kubeconfig-dir string 默认值:"/etc/kubernetes"
kubeconfig 文件的保存路径。
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
--node-name string
指定节点名称。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.58 -
概要
生成控制器管理器要使用的 kubeconfig 文件,并保存到 controller-manager.conf 文件中。
kubeadm init phase kubeconfig controller-manager [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则使用默认的网络接口。
--apiserver-bind-port int32 默认值:6443
要绑定到 API 服务器的端口。
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
controller-manager 操作的帮助命令
--kubeconfig-dir string 默认值:"/etc/kubernetes"
kubeconfig 文件的保存路径。
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs 字符串
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.59 -
概要
生成 kubelet 要使用的 kubeconfig 文件,并将其保存到 kubelet.conf 文件。
请注意,该操作目的是仅 应用于引导集群。在控制平面启动之后,应该从 CSR API 请求所有 kubelet 凭据。
kubeadm init phase kubeconfig kubelet [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则使用默认的网络接口。
--apiserver-bind-port int32 默认值:6443
要绑定到 API 服务器的端口。
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
kubelet 操作的帮助命令
--kubeconfig-dir string 默认值:"/etc/kubernetes"
kubeconfig 文件的保存路径。
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
--node-name string
指定节点的名称。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.60 -
概要
生成调度器(scheduler)要使用的 kubeconfig 文件,并保存到 scheduler.conf 文件中。
kubeadm init phase kubeconfig scheduler [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则使用默认的网络接口。
--apiserver-bind-port int32 默认值:6443
要绑定到 API 服务器的端口。
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
scheduler 操作的帮助命令
--kubeconfig-dir string 默认值:"/etc/kubernetes"
kubeconfig 文件的保存路径。
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.61 -
TLS 引导后更新与 kubelet 相关的设置
kubeadm init phase kubelet-finalize [flags]
示例
# 在 TLS 引导后更新与 kubelet 相关的设置
kubeadm init phase kubelet-finalize all --config
选项
-h, --help
kubelet-finalize 操作的帮助命令
继承于父命令的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
8.1.1.62 -
运行所有 kubelet-finalize 阶段
kubeadm init phase kubelet-finalize all [flags]
示例
# 在 TLS 引导后更新与 kubelet 相关的设置
kubeadm init phase kubelet-finalize all --config
选项
--cert-dir string 默认值: "/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
-h, --help
all 操作的帮助命令
继承于父命令的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
8.1.1.63 -
启用 kubelet 客户端证书轮换
kubeadm init phase kubelet-finalize experimental-cert-rotation [flags]
选项
--cert-dir string Default: "/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
-h, --help
experimental-cert-rotation 操作的帮助命令
继承于父命令的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
8.1.1.64 -
概要
使用 kubelet 配置文件编写一个文件,并使用特定节点的 kubelet 设置编写一个环境文件,然后(重新)启动 kubelet。
kubeadm init phase kubelet-start [flags]
示例
# 从 InitConfiguration 文件中写入带有 kubelet 参数的动态环境文件。
kubeadm init phase kubelet-start --config config.yaml
选项
--config string
kubeadm 配置文件的路径。
--cri-socket string
连接到 CRI 套接字的路径。如果为空,则 kubeadm 将尝试自动检测该值;仅当安装了多个 CRI 或具有非标准 CRI 套接字时,才使用此选项。
-h, --help
kubelet-start 操作的帮助命令
--node-name string
指定节点名称。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.65 -
概要
标记 Node 节点为控制平面节点
kubeadm init phase mark-control-plane [flags]
示例
# 将控制平面标签和污点应用于当前节点,其功能等效于 kubeadm init执行的操作。
kubeadm init phase mark-control-plane --config config.yml
# 将控制平面标签和污点应用于特定节点
kubeadm init phase mark-control-plane --node-name myNode
选项
--config string
kubeadm 配置文件的路径。
-h, --help
mark-control-plane 操作的帮助命令
--node-name string
指定节点名称。
从父命令继承的选项
--rootfs 字符串
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.66 -
概要
运行 kubeadm init 前的启动检查。
kubeadm init phase preflight [flags]
案例
# 使用配置文件对 kubeadm init 进行启动检查。
kubeadm init phase preflight --config kubeadm-config.yml
选项
--config string
kubeadm 配置文件的路径。
-h, --help
preflight 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查列表:例如:'IsPrivilegedUser,Swap'。取值为 'all' 时将忽略检查中的所有错误。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.67 -
概要
此命令并非设计用来单独运行。请参阅可用子命令列表。
kubeadm init phase upload-certs [flags]
选项
--certificate-key string
用于加密 kubeadm-certs Secret 中的控制平面证书的密钥。
--config string
kubeadm 配置文件的路径。
-h, --help
upload-certs 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用来与集群通信的 kubeconfig 文件。
如果此标志未设置,则可以在一组标准的位置搜索现有的 kubeconfig 文件。
--skip-certificate-key-print
不要打印输出用于加密控制平面证书的密钥。
--upload-certs
将控制平面证书上传到 kubeadm-certs Secret。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.68 -
概要
此命令并非设计用来单独运行。请参阅可用的子命令列表。
kubeadm init phase upload-config [flags]
选项
-h, --help
upload-config 操作的帮助命令
从父命令中继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.69 -
概要
将所有配置上传到 ConfigMap
kubeadm init phase upload-config all [flags]
选项
--config string
kubeadm 配置文件的路径。
-h, --help
all 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.70 -
概要
将 kubeadm ClusterConfiguration 上传到 kube-system 命名空间中名为 kubeadm-config 的 ConfigMap 中。
这样就可以正确配置系统组件,并在升级时提供无缝的用户体验。
另外,可以使用 kubeadm 配置。
kubeadm init phase upload-config kubeadm [flags]
示例
# 上传集群配置
kubeadm init phase upload-config --config=myConfig.yaml
选项
--config string
kubeadm 配置文件的路径。
-h, --help
kubeadm 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.71 -
概要
将从 kubeadm InitConfiguration 对象提取的 kubelet 配置上传到集群中 kubelet-config-1.X 形式的
ConfigMap,其中 X 是当前(API 服务器)Kubernetes 版本的次要版本。
kubeadm init phase upload-config kubelet [flags]
示例
# 将 kubelet 配置从 kubeadm 配置文件上传到集群中的 ConfigMap。
kubeadm init phase upload-config kubelet --config kubeadm.yaml
选项
--config string
到 kubeadm 配置文件的路径。
-h, --help
kubelet 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该标签,则可以通过一组标准路径来寻找已有的 kubeconfig 文件。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.72 -
摘要
当节点加入 kubeadm 初始化的集群时,我们需要建立双向信任。
这个过程可以分解为发现(让待加入节点信任 Kubernetes 控制平面节点)和 TLS 引导(让Kubernetes 控制平面节点信任待加入节点)两个部分。
有两种主要的发现方案。
第一种方法是使用共享令牌和 API 服务器的 IP 地址。
第二种是提供一个文件 - 标准 kubeconfig 文件的一个子集。
该文件可以是本地文件,也可以通过 HTTPS URL 下载。
格式是 kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443
、kubeadm join--discovery-file path/to/file.conf
或者kubeadm join --discovery-file https://url/file.conf
。
只能使用其中一种。
如果发现信息是从 URL 加载的,必须使用 HTTPS。
此外,在这种情况下,主机安装的 CA 包用于验证连接。
如果使用共享令牌进行发现,还应该传递 --discovery-token-ca-cert-hash 参数来验证 Kubernetes 控制平面节点提供的根证书颁发机构(CA)的公钥。
此参数的值指定为 "<hash-type>:<hex-encoded-value>",其中支持的哈希类型为 "sha256"。哈希是通过 Subject Public Key Info(SPKI)对象的字节计算的(如 RFC7469)。
这个值可以从 "kubeadm init" 的输出中获得,或者可以使用标准工具进行计算。
可以多次重复 --discovery-token-ca-cert-hash 参数以允许多个公钥。
如果无法提前知道 CA 公钥哈希,则可以通过 --discovery-token-unsafe-skip-ca-verification 参数禁用此验证。
这削弱了kubeadm 安全模型,因为其他节点可能会模仿 Kubernetes 控制平面节点。
TLS 引导机制也通过共享令牌驱动。
这用于向 Kubernetes 控制平面节点进行临时的身份验证,以提交本地创建的密钥对的证书签名请求(CSR)。
默认情况下,kubeadm 将设置 Kubernetes 控制平面节点自动批准这些签名请求。
这个令牌通过 --tls-bootstrap-token abcdef.1234567890abcdef 参数传入。
通常两个部分会使用相同的令牌。
在这种情况下可以使用 --token 参数,而不是单独指定每个令牌。
"join [api-server-endpoint]" 命令执行下列阶段:
preflight Run join pre-flight checks
control-plane-prepare Prepare the machine for serving a control plane
/download-certs [EXPERIMENTAL] Download certificates shared among control-plane nodes from the kubeadm-certs Secret
/certs Generate the certificates for the new control plane components
/kubeconfig Generate the kubeconfig for the new control plane components
/control-plane Generate the manifests for the new control plane components
kubelet-start Write kubelet settings, certificates and (re)start the kubelet
control-plane-join Join a machine as a control plane instance
/etcd Add a new local etcd member
/update-status Register the new control-plane node into the ClusterStatus maintained in the kubeadm-config ConfigMap
/mark-control-plane Mark a node as a control-plane
kubeadm join [api-server-endpoint] [flags]
选项
--apiserver-advertise-address string
如果该节点托管一个新的控制平面实例,则 API 服务器将公布其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--apiserver-bind-port int32 默认值: 6443
如果节点应该托管新的控制平面实例,则为 API 服务器要绑定的端口。
--certificate-key string
使用此密钥可以解密由 init 上传的证书 secret。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--cri-socket string
要连接的 CRI 套接字的路径。如果为空,则 kubeadm 将尝试自动检测此值;仅当安装了多个 CRI 或具有非标准 CRI 插槽时,才使用此选项。
--discovery-file string
对于基于文件的发现,给出用于加载集群信息的文件或者 URL。
--discovery-token string
对于基于令牌的发现,该令牌用于验证从 API 服务器获取的集群信息。
--discovery-token-ca-cert-hash stringSlice
对基于令牌的发现,验证根 CA 公钥是否与此哈希匹配 (格式: "<type>:<value>")。
--discovery-token-unsafe-skip-ca-verification
对于基于令牌的发现,允许在未关联 --discovery-token-ca-cert-hash 参数的情况下添加节点。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
-h, --help
join 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查列表;例如:'IsPrivilegedUser,Swap'。取值为 'all' 时将忽略检查中的所有错误。
--node-name string
指定节点的名称
--skip-phases stringSlice
要跳过的阶段列表
--tls-bootstrap-token string
指定在加入节点时用于临时通过 Kubernetes 控制平面进行身份验证的令牌。
--token string
如果未提供这些值,则将它们用于 discovery-token 令牌和 tls-bootstrap 令牌。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.73 -
概要
使用此命令来调用 join
工作流程的某个阶段
选项
从父命令中继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.74 -
概要
添加作为控制平面实例的机器
kubeadm join phase control-plane-join [flags]
示例
# 将机器作为控制平面实例加入
kubeadm join phase control-plane-join all
选项
-h, --help
control-plane-join 操作的帮助命令
从父命令中继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.75 -
概要
添加作为控制平面实例的机器
kubeadm join phase control-plane-join all [flags]
选项
--apiserver-advertise-address string
如果该节点托管一个新的控制平面实例,则 API 服务器将公布其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--config string
kubeadm 配置文件的路径。
--experimental-control-plane
在此节点上创建一个新的控制平面实例
-h, --help
all 操作的帮助命令
--node-name string
指定节点名称。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.76 -
概要
添加新的本地 etcd 成员
kubeadm join phase control-plane-join etcd [flags]
选项
--apiserver-advertise-address string
如果该节点托管一个新的控制平面实例,则 API 服务器将公布其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是"strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
-h, --help
etcd 操作的帮助命令
--node-name string
指定节点的名称
从父命令中继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.77 -
概要
将 Node 节点标记为控制平面节点
kubeadm join phase control-plane-join mark-control-plane [flags]
选项
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
-h, --help
mark-control-plane 操作的帮助命令
--node-name string
指定节点的名称
从父命令中继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.78 -
概要
将新的控制平面节点注册到 kubeadm-config ConfigMap 维护的 ClusterStatus 中
kubeadm join phase control-plane-join update-status [flags]
选项
--apiserver-advertise-address string
如果该节点托管一个新的控制平面实例,则 API 服务器将公布其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
-h, --help
update-status 操作的帮助命令
--node-name string
指定节点名称。
从父命令中继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.79 -
概要
准备为控制平面服务的机器
kubeadm join phase control-plane-prepare [flags]
示例
# 准备为控制平面服务的机器
kubeadm join phase control-plane-prepare all
选项
-h, --help
control-plane-prepare 操作的帮助命令
从父命令中继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.80 -
概要
准备为控制平面服务的机器
kubeadm join phase control-plane-prepare all [api-server-endpoint] [flags]
选项
--apiserver-advertise-address string
如果该节点托管一个新的控制平面实例,则 API 服务器将公布其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--apiserver-bind-port int32 默认值:6443
如果该节点托管一个新的控制平面实例,则为 API 服务器要绑定的端口。
--certificate-key string
使用此密钥解密由 init 上传的证书 secrets。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--discovery-file string
对于基于文件的发现,给出用于加载集群信息的文件或者 URL。
--discovery-token string
对于基于令牌的发现,该令牌用于验证从 API 服务器获取的集群信息。
--discovery-token-ca-cert-hash stringSlice
对于基于令牌的发现,请验证根 CA 公钥是否匹配此哈希值(格式:"<type>:<value>")。
--discovery-token-unsafe-skip-ca-verification
对于基于令牌的发现,允许在未关联 --discovery-token-ca-cert-hash 参数的情况下添加节点。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
-h, --help
all 操作的帮助命令
--node-name string
指定节点名称。
--tls-bootstrap-token string
指定在加入节点时用于临时通过 Kubernetes 控制平面进行身份验证的令牌。
--token string
如果未提供这些值,则将它们用于 discovery-token 令牌和 tls-bootstrap 令牌。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.81 -
概要
为新的控制平面组件生成证书
kubeadm join phase control-plane-prepare certs [api-server-endpoint] [flags]
选项
--apiserver-advertise-address string
如果该节点托管一个新的控制平面实例,则 API 服务器将公布其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--discovery-file string
对于基于文件的发现,给出用于加载集群信息的文件或者 URL。
--discovery-token string
对于基于令牌的发现,该令牌用于验证从 API 服务器获取的集群信息。
--discovery-token-ca-cert-hash stringSlice
对于基于令牌的发现,请验证根 CA 公钥是否匹配此哈希值(格式:"<type>:<value>")。
--discovery-token-unsafe-skip-ca-verification
对于基于令牌的发现,允许在未关联 --discovery-token-ca-cert-hash 参数的情况下添加节点。
-h, --help
certs 操作的帮助命令
--node-name string
指定节点名称。
--tls-bootstrap-token string
指定在加入节点时用于临时通过 Kubernetes 控制平面进行身份验证的令牌。
--token string
如果未提供这些值,则将它们用于 discovery-token 令牌和 tls-bootstrap 令牌。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.82 -
概要
为新的控制平面组件生成清单(manifest)
kubeadm join phase control-plane-prepare control-plane [flags]
选项
--apiserver-advertise-address string
对于将要托管新的控制平面实例的节点,指定 API 服务器将公布的其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--apiserver-bind-port int32 默认值:6443
针对将要托管新的控制平面实例的节点,设置 API 服务器要绑定的端口。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
-h, --help
control-plane 操作的帮助命令
从父命令中继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.83 -
概要
[实验]从 kubeadm-certs Secret 下载控制平面节点之间共享的证书
kubeadm join phase control-plane-prepare download-certs [api-server-endpoint] [flags]
选项
--certificate-key string
使用此密钥可以解密由 init 上传的证书 secret。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--discovery-file string
对于基于文件的发现,给出用于加载集群信息的文件或者 URL。
--discovery-token string
对于基于令牌的发现,该令牌用于验证从 API 服务器获取的集群信息。
--discovery-token-ca-cert-hash stringSlice
对于基于令牌的发现,请验证根 CA 公钥是否匹配此哈希值(格式:"<type>:<value>")。
--discovery-token-unsafe-skip-ca-verification
对于基于令牌的发现,允许在未关联 --discovery-token-ca-cert-hash 参数的情况下添加节点。
-h, --help
kubeconfig 操作的帮助命令
--tls-bootstrap-token string
指定在加入节点时用于临时通过 Kubernetes 控制平面进行身份验证的令牌。
--token string
如果未提供这些值,则将它们用于 discovery-token 令牌和 tls-bootstrap 令牌。
从父命令中继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.84 -
概要
为新的控制平面组件生成 kubeconfig
kubeadm join phase control-plane-prepare kubeconfig [api-server-endpoint] [flags]
选项
--certificate-key string
使用此密钥可以解密由 init 上传的证书 secret。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--discovery-file string
对于基于文件的发现,给出用于加载集群信息的文件或者 URL。
--discovery-token string
对于基于令牌的发现,该令牌用于验证从 API 服务器获取的集群信息。
--discovery-token-ca-cert-hash stringSlice
对于基于令牌的发现,请验证根 CA 公钥是否匹配此哈希值(格式:"<type>:<value>")。
--discovery-token-unsafe-skip-ca-verification
对于基于令牌的发现,允许在未关联 --discovery-token-ca-cert-hash 参数的情况下添加节点。
-h, --help
kubeconfig 操作的帮助命令
--tls-bootstrap-token string
指定在加入节点时用于临时通过 Kubernetes 控制平面进行身份验证的令牌。
--token string
如果未提供这些值,则将它们用于 discovery-token 令牌和 tls-bootstrap 令牌。
从父命令中继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.85 -
概要
生成一个包含 KubeletConfiguration 的文件和一个包含特定于节点的 kubelet 配置的环境文件,然后(重新)启动 kubelet。
kubeadm join phase kubelet-start [api-server-endpoint] [flags]
选项
--config string
kubeadm 配置文件的路径。
--cri-socket string
提供给 CRI 套接字建立连接的路径。如果为空,则 kubeadm 将尝试自动检测该值;仅当安装了多个 CRI 或具有非标准 CRI 套接字时,才使用此选项。
--discovery-file string
For file-based discovery, a file or URL from which to load cluster information.
对于基于文件的发现,给出用于加载集群信息的文件或者 URL。
--discovery-token string
对于基于令牌的发现,该令牌用于验证从 API 服务器获取的集群信息。
--discovery-token-ca-cert-hash stringSlice
对于基于令牌的发现,验证根 CA 公钥是否匹配此哈希值(格式:"<type>:<value>")。
--discovery-token-unsafe-skip-ca-verification
对于基于令牌的发现,允许在未关联 --discovery-token-ca-cert-hash 参数的情况下添加节点。
-h, --help
kubelet-start 操作的帮助命令
--node-name string
指定节点名称。
--tls-bootstrap-token string
指定在加入节点时用于临时通过 Kubernetes 控制平面进行身份验证的令牌。
--token string
如果未提供这些值,则将它们用于 discovery-token 令牌和 tls-bootstrap 令牌。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.86 -
概要
运行 kubeadm join 命令添加节点前检查。
kubeadm join phase preflight [api-server-endpoint] [flags]
示例
# 使用配置文件运行 kubeadm join 命令添加节点前检查。
kubeadm join phase preflight --config kubeadm-config.yml
选项
--apiserver-advertise-address string
对于将要托管新的控制平面实例的节点,指定 API 服务器将公布的其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--apiserver-bind-port int32 默认值:6443
针对将要托管新的控制平面实例的节点,设置 API 服务器要绑定的端口。
--certificate-key string
使用此密钥可以解密由 `init` 操作上传的证书 secret。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--cri-socket string
提供给 CRI 套接字建立连接的路径。如果为空,则 kubeadm 将尝试自动检测该值;仅当安装了多个 CRI 或具有非标准 CRI 套接字时,才使用此选项。
--discovery-file string
对于基于文件的发现,给出用于加载集群信息的文件或者 URL。
--discovery-token string
对于基于令牌的发现,该令牌用于验证从 API 服务器获取的集群信息。
--discovery-token-ca-cert-hash stringSlice
对于基于令牌的发现,验证根 CA 公钥是否匹配此哈希值(格式:"<type>:<value>")。
--discovery-token-unsafe-skip-ca-verification
对于基于令牌的发现,允许在未关联 --discovery-token-ca-cert-hash 参数的情况下添加节点。
-h, --help
preflight 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查列表;例如:'IsPrivilegedUser,Swap'。取值为 'all' 时将忽略检查中的所有错误。
--node-name string
指定节点名称。
--tls-bootstrap-token string
指定在加入节点时用于临时通过 Kubernetes 控制平面进行身份验证的令牌。
--token string
如果未提供这些值,则将它们用于 discovery-token 令牌和 tls-bootstrap 令牌。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.87 -
Kubeconfig 文件工具。
概要
kubeconfig 文件工具。
选项
-h, --help
kubeconfig 操作的帮助命令
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
8.1.1.88 -
为其他用户输出一个 kubeconfig 文件。
概要
为其他用户输出一个 kubeconfig 文件。
kubeadm alpha kubeconfig user [flags]
示例
# 使用名为 bar 的 kubeadm 配置文件为名为 foo 的另一用户输出 kubeconfig 文件
kubeadm kubeconfig user --client-name=foo --config=bar
选项
--client-name string
用户名。如果生成客户端证书,则用作其 CN。
--config string
指向 kubeadm 配置文件的路径
-h, --help
user 操作的帮助命令
--org strings
客户端证书的组织。如果创建客户端证书,此值将用作其 O 字段值。
--token string
应该用此令牌做为 kubeconfig 的身份验证机制,而不是客户端证书
--validity-period duration Default: 8760h0m0s
客户证书的合法期限。所设置值为相对当前时间的偏移。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机的根目录。
8.1.1.89 -
概要
尽最大努力还原通过 'kubeadm init' 或者 'kubeadm join' 操作对主机所做的更改
"reset" 命令执行以下阶段:
preflight Run reset pre-flight checks
update-cluster-status Remove this node from the ClusterStatus object.
remove-etcd-member Remove a local etcd member.
cleanup-node Run cleanup node.
kubeadm reset [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的目录路径。如果已指定,则需要清空此目录。
--cri-socket string
要连接的 CRI 套接字的路径。如果为空,则 kubeadm 将尝试自动检测此值;仅当安装了多个CRI 或具有非标准 CRI 插槽时,才使用此选项。
-f, --force
在不提示确认的情况下重置节点。
-h, --help
reset 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查列表;例如:'IsPrivilegedUser,Swap'。取值为 'all' 时将忽略检查中的所有错误。
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该标志,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--skip-phases stringSlice
要跳过的阶段列表
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.90 -
概要
使用此命令来调用 reset
工作流程的某个阶段
选项
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.91 -
概要
执行 cleanup node(清理节点)操作。
kubeadm reset phase cleanup-node [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的目录路径。如果已指定,则需要清空此目录。
--cri-socket string
要连接的 CRI 套接字的路径。如果为空,则 kubeadm 将尝试自动检测此值;仅当安装了多个CRI 或具有非标准 CRI 插槽时,才使用此选项。
-h, --help
cleanup-node 操作的帮助命令
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.92 -
概要
kubeadm reset(重置)前运行启动前检查。
kubeadm reset phase preflight [flags]
选项
-f, --force
在不提示确认的情况下重置节点。
-h, --help
preflight 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查列表;例如:'IsPrivilegedUser,Swap'。取值为 'all' 时将忽略检查中的所有错误。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.93 -
概要
上传关于当前状态的配置,以便 'kubeadm upgrade' 以后可以知道如何配置升级后的集群。
kubeadm config upload [flags]
选项
-h, --help
upload 操作的帮助信息
从父命令继承的选项
--kubeconfig string 默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
8.1.1.94 -
概要
如果该节点是控制平面节点,从 ClusterStatus 对象中删除该节点。
kubeadm reset phase update-cluster-status [flags]
选项
-h, --help
update-cluster-status 操作的帮助命令
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.95 -
概要
此命令管理引导令牌(bootstrap token)。它是可选的,仅适用于高级用例。
简而言之,引导令牌(bootstrap token)用于在客户端和服务器之间建立双向信任。
当客户端(例如,即将加入集群的节点)需要时,可以使用引导令牌相信正在与之通信的服务器。
然后可以使用具有 “签名” 的引导令牌。
引导令牌还可以作为一种允许对 API 服务器进行短期身份验证的方法(令牌用作 API 服务器信任客户端的方式),例如用于执行 TLS 引导程序。
引导令牌准确来说是什么?
它是位于 kube-system 命名空间中类型为 “bootstrap.kubernetes.io/token” 的一个 Secret。
引导令牌的格式必须为 “[a-z0-9]{6}.[a-z0-9]{16}”,前一部分是公共令牌 ID,而后者是令牌秘钥,必须在任何情况下都保密!
必须将 Secret 的名称命名为 “bootstrap-token-(token-id)”。
您可以在此处阅读有关引导令牌(bootstrap token)的更多信息:
/docs/admin/bootstrap-tokens/
kubeadm token [flags]
选项
--dry-run
是否启用 `dry-run` 模式
-h, --help
token 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置,则搜索一组标准位置以查找现有 kubeconfig 文件。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.96 -
概要
这个命令将为你创建一个引导令牌。
您可以设置此令牌的用途,"有效时间" 和可选的人性化的描述。
这里的 [token] 是指将要生成的实际令牌。
该令牌应该是一个通过安全机制生成的随机令牌,形式为 "[a-z0-9]{6}.[a-z0-9]{16}"。
如果没有给出 [token],kubeadm 将生成一个随机令牌。
kubeadm token create [token]
选项
--config string
kubeadm 配置文件的路径。
--description string
针对令牌用途的人性化的描述。
--groups stringSlice 默认值:[system:bootstrappers:kubeadm:default-node-token]
此令牌用于身份验证时将进行身份验证的其他组。必须匹配 "\\Asystem:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]\\z"
-h, --help
create 操作的帮助命令
--print-join-command
不仅仅打印令牌,而是打印使用令牌加入集群所需的完整 'kubeadm join' 参数。
--ttl duration 默认值:24h0m0s
令牌有效时间,超过该时间令牌被自动删除。(例如: 1s, 2m, 3h)。如果设置为 '0',令牌将永远不过期。
--usages stringSlice 默认值:[signing,authentication]
描述可以使用此令牌的方式。你可以多次使用 `--usages` 或者提供一个以逗号分隔的选项列表。合法选项有: [signing,authentication]
从父命令继承的选项
--dry-run
是否启用 `dry-run` 运行模式
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.97 -
概要
这个命令将为你删除指定的引导令牌列表。
[token-value]
是要删除的 "[a-z0-9]{6}.[a-z0-9]{16}" 形式的完整令牌或者是 "[a-z0-9]{6}" 形式的的令牌 ID。
kubeadm token delete [token-value] ...
选项
-h, --help
delete 操作的帮助命令
从父命令继承的选项
--dry-run
是否启用 `dry-run` 运行模式
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.98 -
概要
此命令将打印一个随机生成的可以被 "init" 和 "join" 命令使用的引导令牌。
您不必使用此命令来生成令牌。你可以自己设定,只要格式符合 "[a-z0-9]{6}.[a-z0-9]{16}"。这个命令提供是为了方便生成规定格式的令牌。
您也可以使用 "kubeadm init" 并且不指定令牌,该命令会生成一个令牌并打印出来。
kubeadm token generate [flags]
选项
-h, --help
generate 操作的帮助命令
从父命令继承的选项
--dry-run
是否启用 `dry-run` 运行模式
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.99 -
概要
此命令将为您列出所有的引导令牌。
kubeadm token list [flags]
选项
--allow-missing-template-keys 默认值:true
如果设置为 true,则在模板中缺少字段或哈希表的键时忽略模板中的任何错误。
仅适用于 golang 和 jsonpath 输出格式。
-o, --experimental-output string 默认值:"text"
输出格式:text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file 其中之一
-h, --help
list 操作的帮助命令
从父命令继承的选项
--dry-run
是否启用 `dry-run` 模式
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 kubeconfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 kubeconfig 文件。
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.100 -
概要
此命令能将集群平滑升级到新版本
kubeadm upgrade [flags]
选项
-h, --help
upgrade 操作的帮助命令
继承于父命令的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.101 -
概要
将 Kubernetes 集群升级到指定版本
kubeadm upgrade apply [version]
选项
--allow-experimental-upgrades
显示 Kubernetes 的不稳定版本作为升级替代方案,并允许升级到 Kubernetes 的 alpha/beta 或 RC 版本。
--allow-release-candidate-upgrades
显示 Kubernetes 的候选版本作为升级替代方案,并允许升级到 Kubernetes 的 RC 版本。
--certificate-renewal Default: true
执行升级期间更改的组件所使用的证书的更新。
--config string
kubeadm 配置文件的路径。
--dry-run
不要更改任何状态,只输出要执行的操作。
--etcd-upgrade 默认值: true
执行 etcd 的升级。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
--feature-gates string
一组键值对,用于描述各种功能。选项包括:
IPv6DualStack=true|false (ALPHA - 默认=false)
PublicKeysECDSA=true|false (ALPHA - 默认=false)
-f, --force
强制升级,但可能无法满足某些要求。这也意味着非交互模式。
-h, --help
apply 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查列表;例如:'IsPrivilegedUser,Swap'。取值为 'all' 时将忽略检查中的所有错误。
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置标志,则在相关目录下搜索以查找现有 kubeconfig 文件。
--print-config
指定是否应打印将在升级中使用的配置文件。
-y, --yes
执行升级,不提示确认(非交互模式)。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.102 -
概述
显示哪些差异将被应用于现有的静态 pod 资源清单。参考: kubeadm upgrade apply --dry-run
kubeadm upgrade diff [version] [flags]
选项
--api-server-manifest string 默认值:"/etc/kubernetes/manifests/kube-apiserver.yaml"
API服务器清单的路径
--config string
kubeadm 配置文件的路径
-c, --context-lines int 默认值:3
差异中有多少行上下文
--controller-manager-manifest string 默认值: "/etc/kubernetes/manifests/kube-controller-manager.yaml"
控制器清单的路径
-h, --help
帮助
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件,如果标志是未设置,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--scheduler-manifest string 默认值:"/etc/kubernetes/manifests/kube-scheduler.yaml"
调度程序清单的路径
从父命令继承的选项
--rootfs string
[EXPERIMENTAL] “真实”主机根文件系统的路径。
8.1.1.103 -
概要
升级集群中某个节点的命令
"node" 命令执行以下阶段:
preflight 执行节点升级前检查
control-plane 如果存在的话,升级部署在该节点上的管理面实例
kubelet-config 更新该节点上的 kubelet 配置
kubeadm upgrade node [flags]
选项
--certificate-renewal
对升级期间变化的组件所使用的证书执行更新。
--dry-run
不更改任何状态,只输出将要执行的操作。
--etcd-upgrade 默认值: true
执行 etcd 的升级。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
-h, --help
node 操作的帮助命令
--kubeconfig string 默认值: "/etc/kubernetes/admin.conf"
用于与集群交互的 kubeconfig 文件。如果参数未指定,将从一系列标准位置检索存在的 kubeconfig 文件。
--kubelet-version string
升级后 *期望的* kubelet 配置版本。如未指定,将使用 kubeadm-config ConfigMap 中的 KubernetesVersion
--skip-phases stringSlice
要跳过的阶段的列表
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.104 -
概要
使用此命令调用 node 工作流的某个阶段
选项
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.105 -
概要
升级部署在此节点上的控制平面实例,如果有的话
kubeadm upgrade node phase control-plane [flags]
选项
--certificate-renewal
更新在升级期间变更的组件使用的证书。
--dry-run
不改变任何状态,只输出将要执行的动作。
--etcd-upgrade 默认值: true
执行 etcd 的升级。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
-h, --help
control-plane 的帮助信息
--kubeconfig string 默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
从父命令继承的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
8.1.1.106 -
从群集中 "kubelet-config-1.X" 的 ConfigMap 下载 kubelet 配置,其中 X 是kubelet 的次要版本。
kubeadm 使用 --kubelet-version 参数来确定所需的 kubelet 版本。
kubeadm upgrade node phase kubelet-config [flags]
选项
--dry-run
不改变任何状态,只输出将要执行的操作
-h, --help
配置操作的帮助信息
--kubeconfig string 默认值: "/etc/kubernetes/kubelet.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--kubelet-version string
升级后的 kubelet 的*期望*版本。
从父命令继承的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
8.1.1.107 -
执行 kubeadm 升级节点的预检。
kubeadm upgrade node phase preflight [flags]
选项
-h, --help
preflight 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查清单。示例:'IsPrivilegedUser,Swap'。值为'all'表示忽略所有检查的错误。
继承于父命令的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
8.1.1.108 -
概述
检查可升级到哪些版本,并验证您当前的集群是否可升级。 要跳过互联网检查,请传递可选的 [version] 参数
kubeadm upgrade plan [version] [flags]
选项
--allow-experimental-upgrades
显示不稳定版本的 Kubernetes 作为升级替代方案,并允许升级到 Kubernetes 的 Alpha/Beta/发行候选版本。
--allow-release-candidate-upgrades
显示 Kubernetes 的发行候选版本作为升级选择,并允许升级到 Kubernetes 的发行候选版本。
--config string
配置文件的路径。
--feature-gates string
一组描述各种特征特性门控的键值对。选项有:IPv6DualStack=true|false (ALPHA - default=false) PublicKeysECDSA=true|false (ALPHA - default=false)
-h, --help
帮助
--ignore-preflight-errors stringSlice
检查清单,其错误将显示为警告。 例如:“IsPrivilegedUser,Swap”。 值 “all” 忽略所有检查的错误。
--kubeconfig string Default: "/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。 如果标志为未设置,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--print-config
指定是否打印将在升级中使用的配置文件。
从父命令继承的选项
--rootfs string
[EXPERIMENTAL] “真实”主机根文件系统的路径。
8.1.1.109 -
概要
打印 kubeadm 的版本
kubeadm version [flags]
选项
-h, --help
version 操作的帮助命令
-o, --output string
输出格式;可用的选项有 'yaml', 'json' 和 'short'
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.1.110 -
此目录下的所有文件都是从其他仓库自动生成的。 不要人工编辑它们。 您必须在上游仓库中编辑它们
8.1.2 - kubeadm init
此命令初始化一个 Kubernetes 控制平面节点。
概要
运行此命令来搭建 Kubernetes 控制平面节点。
"init" 命令执行以下阶段:
preflight Run pre-flight checks
certs Certificate generation
/ca Generate the self-signed Kubernetes CA to provision identities for other Kubernetes components
/apiserver Generate the certificate for serving the Kubernetes API
/apiserver-kubelet-client Generate the certificate for the API server to connect to kubelet
/front-proxy-ca Generate the self-signed CA to provision identities for front proxy
/front-proxy-client Generate the certificate for the front proxy client
/etcd-ca Generate the self-signed CA to provision identities for etcd
/etcd-server Generate the certificate for serving etcd
/etcd-peer Generate the certificate for etcd nodes to communicate with each other
/etcd-healthcheck-client Generate the certificate for liveness probes to healthcheck etcd
/apiserver-etcd-client Generate the certificate the apiserver uses to access etcd
/sa Generate a private key for signing service account tokens along with its public key
kubeconfig Generate all kubeconfig files necessary to establish the control plane and the admin kubeconfig file
/admin Generate a kubeconfig file for the admin to use and for kubeadm itself
/kubelet Generate a kubeconfig file for the kubelet to use *only* for cluster bootstrapping purposes
/controller-manager Generate a kubeconfig file for the controller manager to use
/scheduler Generate a kubeconfig file for the scheduler to use
kubelet-start Write kubelet settings and (re)start the kubelet
control-plane Generate all static Pod manifest files necessary to establish the control plane
/apiserver Generates the kube-apiserver static Pod manifest
/controller-manager Generates the kube-controller-manager static Pod manifest
/scheduler Generates the kube-scheduler static Pod manifest
etcd Generate static Pod manifest file for local etcd
/local Generate the static Pod manifest file for a local, single-node local etcd instance
upload-config Upload the kubeadm and kubelet configuration to a ConfigMap
/kubeadm Upload the kubeadm ClusterConfiguration to a ConfigMap
/kubelet Upload the kubelet component config to a ConfigMap
upload-certs Upload certificates to kubeadm-certs
mark-control-plane Mark a node as a control-plane
bootstrap-token Generates bootstrap tokens used to join a node to a cluster
kubelet-finalize Updates settings relevant to the kubelet after TLS bootstrap
/experimental-cert-rotation Enable kubelet client certificate rotation
addon Install required addons for passing Conformance tests
/coredns Install the CoreDNS addon to a Kubernetes cluster
/kube-proxy Install the kube-proxy addon to a Kubernetes cluster
kubeadm init [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则使用默认网络接口。
--apiserver-bind-port int32 默认值:6443
API 服务器绑定的端口。
--apiserver-cert-extra-sans stringSlice
用于 API Server 服务证书的可选附加主题备用名称(SAN)。可以是 IP 地址和 DNS 名称。
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--certificate-key string
用于加密 kubeadm-certs Secret 中的控制平面证书的密钥。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
--cri-socket string
要连接的 CRI 套接字的路径。如果为空,则 kubeadm 将尝试自动检测此值;仅当安装了多个 CRI 或具有非标准 CRI 插槽时,才使用此选项。
--dry-run
不要应用任何更改;只是输出将要执行的操作。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
--feature-gates string
一组用来描述各种功能特性的键值(key=value)对。选项是: IPv6DualStack=true|false (ALPHA - default=false)
-h, --help
init 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查列表;例如:'IsPrivilegedUser,Swap'。取值为 'all' 时将忽略检查中的所有错误。
--image-repository string 默认值:"k8s.gcr.io"
选择用于拉取控制平面镜像的容器仓库
--kubernetes-version string 默认值:"stable-1"
为控制平面选择一个特定的 Kubernetes 版本。
--node-name string
指定节点的名称。
--pod-network-cidr string
指明 pod 网络可以使用的 IP 地址段。如果设置了这个参数,控制平面将会为每一个节点自动分配 CIDRs。
--service-cidr string 默认值:"10.96.0.0/12"
为服务的虚拟 IP 地址另外指定 IP 地址段
--service-dns-domain string 默认值:"cluster.local"
为服务另外指定域名,例如:"myorg.internal"。
--skip-certificate-key-print
不要打印用于加密控制平面证书的密钥。
--skip-phases stringSlice
要跳过的阶段列表
--skip-token-print
跳过打印 'kubeadm init' 生成的默认引导令牌。
--token string
这个令牌用于建立控制平面节点与工作节点间的双向通信。格式为 [a-z0-9]{6}\.[a-z0-9]{16} - 示例:abcdef.0123456789abcdef
--token-ttl duration 默认值:24h0m0s
令牌被自动删除之前的持续时间(例如 1 s,2 m,3 h)。如果设置为 '0',则令牌将永不过期
--upload-certs
将控制平面证书上传到 kubeadm-certs Secret。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
Init 命令的工作流程
kubeadm init
命令通过执行下列步骤来启动一个 Kubernetes 控制平面节点。
在做出变更前运行一系列的预检项来验证系统状态。一些检查项目仅仅触发警告,
其它的则会被视为错误并且退出 kubeadm,除非问题得到解决或者用户指定了
--ignore-preflight-errors=<错误列表>
参数。
生成一个自签名的 CA 证书来为集群中的每一个组件建立身份标识。
用户可以通过将其放入 --cert-dir
配置的证书目录中(默认为 /etc/kubernetes/pki
)
来提供他们自己的 CA 证书以及/或者密钥。
APIServer 证书将为任何 --apiserver-cert-extra-sans
参数值提供附加的 SAN 条目,必要时将其小写。
将 kubeconfig 文件写入 /etc/kubernetes/
目录以便 kubelet、控制器管理器和调度器用来连接到
API 服务器,它们每一个都有自己的身份标识,同时生成一个名为 admin.conf
的独立的 kubeconfig
文件,用于管理操作。
为 API 服务器、控制器管理器和调度器生成静态 Pod 的清单文件。假使没有提供一个外部的 etcd
服务的话,也会为 etcd 生成一份额外的静态 Pod 清单文件。
静态 Pod 的清单文件被写入到 /etc/kubernetes/manifests
目录;
kubelet 会监视这个目录以便在系统启动的时候创建 Pod。
一旦控制平面的 Pod 都运行起来, kubeadm init
的工作流程就继续往下执行。
对控制平面节点应用标签和污点标记以便不会在它上面运行其它的工作负载。
生成令牌,将来其他节点可使用该令牌向控制平面注册自己。
如 kubeadm token 文档所述,
用户可以选择通过 --token
提供令牌。
为了使得节点能够遵照启动引导令牌
和 TLS 启动引导
这两份文档中描述的机制加入到集群中,kubeadm 会执行所有的必要配置:
更多相关信息,请查看 kubeadm join 。
通过 API 服务器安装一个 DNS 服务器 (CoreDNS) 和 kube-proxy 附加组件。
在 Kubernetes 版本 1.11 和更高版本中,CoreDNS 是默认的 DNS 服务器。
请注意,尽管已部署 DNS 服务器,但直到安装 CNI 时才调度它。
警告: 从 v1.18 开始,在 kubeadm 中使用 kube-dns 的支持已被废弃,并已在 v1.21 版本中删除。
在 kubeadm 中使用 init phases
Kubeadm 允许你使用 kubeadm init phase
命令分阶段创建控制平面节点。
要查看阶段和子阶段的有序列表,可以调用 kubeadm init --help
。
该列表将位于帮助屏幕的顶部,每个阶段旁边都有一个描述。
注意,通过调用 kubeadm init
,所有阶段和子阶段都将按照此确切顺序执行。
某些阶段具有唯一的标志,因此,如果要查看可用选项的列表,请添加 --help
,例如:
sudo kubeadm init phase control-plane controller-manager --help
你也可以使用 --help
查看特定父阶段的子阶段列表:
sudo kubeadm init phase control-plane --help
kubeadm init
还公开了一个名为 --skip-phases
的参数,该参数可用于跳过某些阶段。
参数接受阶段名称列表,并且这些名称可以从上面的有序列表中获取。
例如:
sudo kubeadm init phase control-plane all --config= configfile.yaml
sudo kubeadm init phase etcd local --config= configfile.yaml
# 你现在可以修改控制平面和 etcd 清单文件
sudo kubeadm init --skip-phases= control-plane,etcd --config= configfile.yaml
该示例将执行的操作是基于 configfile.yaml
中的配置在 /etc/kubernetes/manifests
中写入控制平面和 etcd 的清单文件。
这允许你修改文件,然后使用 --skip-phases
跳过这些阶段。
通过调用最后一个命令,你将使用自定义清单文件创建一个控制平面节点。
结合一份配置文件来使用 kubeadm init
注意: 配置文件的功能仍然处于 alpha 状态并且在将来的版本中可能会改变。
通过一份配置文件而不是使用命令行参数来配置 kubeadm init
命令是可能的,
但是一些更加高级的功能只能够通过配置文件设定。
这份配置文件通过 --config
选项参数指定的,
它必须包含 ClusterConfiguration
结构,并可能包含更多由 ---\n
分隔的结构。
在某些情况下,可能不允许将 --config
与其他标志混合使用。
可以使用 kubeadm config print
命令打印出默认配置。
如果你的配置没有使用最新版本,
推荐 使用 kubeadm config migrate
命令进行迁移。
有关配置的字段和用法的更多信息,
你可以访问 API 参考页面并从
列表
中选择一个版本。
添加 kube-proxy 参数
kubeadm 配置中有关 kube-proxy 的说明请查看:
使用 kubeadm 启用 IPVS 模式的说明请查看:
向控制平面组件传递自定义的命令行参数
有关向控制平面组件传递命令行参数的说明请查看:
控制平面命令行参数
使用自定义的镜像
默认情况下, kubeadm 会从 k8s.gcr.io
仓库拉取镜像。如果请求的 Kubernetes 版本是 CI 标签
(例如 ci/latest
),则使用 gcr.io/k8s-staging-ci-images
。
你可以通过使用带有配置文件的 kubeadm 来重写此操作。
允许的自定义功能有:
使用其他的 imageRepository
来代替 k8s.gcr.io
。
将 useHyperKubeImage
设置为 true
,使用 HyperKube 镜像。
为 etcd 或 DNS 附件提供特定的 imageRepository
和 imageTag
。
请注意配置文件中的配置项 kubernetesVersion
或者命令行参数 --kubernetes-version
会影响到镜像的版本。
将控制平面证书上传到集群
通过将参数 --upload-certs
添加到 kubeadm init
,你可以将控制平面证书临时上传到集群中的 Secret。
请注意,此 Secret 将在 2 小时后自动过期。证书使用 32 字节密钥加密,可以使用 --certificate-key
指定。
通过将 --control-plane
和 --certificate-key
传递给 kubeadm join
,
可以在添加其他控制平面节点时使用相同的密钥下载证书。
以下阶段命令可用于证书到期后重新上传证书:
kubeadm init phase upload-certs --upload-certs --certificate-key= SOME_VALUE --config= SOME_YAML_FILE
如果未将参数 --certificate-key
传递给 kubeadm init
和 kubeadm init phase upload-certs
,
则会自动生成一个新密钥。
以下命令可用于按需生成新密钥:
kubeadm certs certificate-key
使用 kubeadm 管理证书
有关使用 kubeadm 进行证书管理的详细信息,请参阅
使用 kubeadm 进行证书管理 。
该文档包括有关使用外部 CA,自定义证书和证书更新的信息。
管理 kubeadm 为 kubelet 提供的 systemd 配置文件
kubeadm
包自带了关于 systemd
如何运行 kubelet
的配置文件。
请注意 kubeadm
客户端命令行工具永远不会修改这份 systemd
配置文件。
这份 systemd
配置文件属于 kubeadm DEB/RPM 包。
有关更多信息,请阅读
管理 systemd 的 kubeadm 内嵌文件 。
结合 CRI 运行时使用 kubeadm
默认情况下,kubeadm 尝试检测你的容器运行环境。有关此检测的更多详细信息,请参见
kubeadm CRI 安装指南 。
设置节点的名称
默认情况下, kubeadm
基于机器的主机地址分配一个节点名称。你可以使用 --node-name
参数覆盖此设置。
此标识将合适的
--hostname-override
值传递给 kubelet。
在没有互联网连接的情况下运行 kubeadm
要在没有互联网连接的情况下运行 kubeadm,你必须提前拉取所需的控制平面镜像。
你可以使用 kubeadm config images
子命令列出并拉取镜像:
kubeadm config images list
kubeadm config images pull
kubeadm 需要的所有镜像,例如 k8s.gcr.io/kube-*
、k8s.gcr.io/etcd
和 k8s.gcr.io/pause
都支持多种架构。
kubeadm 自动化
除了像文档 kubeadm 基础教程
中所描述的那样,将从 kubeadm init
取得的令牌复制到每个节点,
你还可以并行地分发令牌以实现简单自动化。
要实现自动化,你必须知道控制平面节点启动后将拥有的 IP 地址,或使用 DNS 名称或负载均衡器的地址。
生成一个令牌。这个令牌必须具有以下格式:< 6 个字符的字符串>.< 16 个字符的字符串>
。
更加正式的说法是,它必须符合以下正则表达式:[a-z0-9]{6}\.[a-z0-9]{16}
。
kubeadm 可以为你生成一个令牌:
使用这个令牌同时启动控制平面节点和工作节点。它们一旦运行起来应该就会互相寻找对方并且建立集群。
同样的 --token
参数可以同时用于 kubeadm init
和 kubeadm join
命令。
当加入其他控制平面节点时,可以对 --certificate-key
执行类似的操作。可以使用以下方式生成密钥:
kubeadm certs certificate-key
一旦集群启动起来,你就可以从控制平面节点的 /etc/kubernetes/admin.conf
文件获取管理凭证,
并使用这个凭证同集群通信。
注意这种搭建集群的方式在安全保证上会有一些宽松,因为这种方式不允许使用 --discovery-token-ca-cert-hash
来验证根 CA 的哈希值(因为当配置节点的时候,它还没有被生成)。
更多信息请参阅 kubeadm join 文档。
接下来
8.1.3 - kubeadm join
此命令用来初始化 Kubernetes 工作节点并将其加入集群。
摘要
当节点加入 kubeadm 初始化的集群时,我们需要建立双向信任。
这个过程可以分解为发现(让待加入节点信任 Kubernetes 控制平面节点)和 TLS 引导(让Kubernetes 控制平面节点信任待加入节点)两个部分。
有两种主要的发现方案。
第一种方法是使用共享令牌和 API 服务器的 IP 地址。
第二种是提供一个文件 - 标准 kubeconfig 文件的一个子集。
该文件可以是本地文件,也可以通过 HTTPS URL 下载。
格式是 kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443
、kubeadm join--discovery-file path/to/file.conf
或者kubeadm join --discovery-file https://url/file.conf
。
只能使用其中一种。
如果发现信息是从 URL 加载的,必须使用 HTTPS。
此外,在这种情况下,主机安装的 CA 包用于验证连接。
如果使用共享令牌进行发现,还应该传递 --discovery-token-ca-cert-hash 参数来验证 Kubernetes 控制平面节点提供的根证书颁发机构(CA)的公钥。
此参数的值指定为 "<hash-type>:<hex-encoded-value>",其中支持的哈希类型为 "sha256"。哈希是通过 Subject Public Key Info(SPKI)对象的字节计算的(如 RFC7469)。
这个值可以从 "kubeadm init" 的输出中获得,或者可以使用标准工具进行计算。
可以多次重复 --discovery-token-ca-cert-hash 参数以允许多个公钥。
如果无法提前知道 CA 公钥哈希,则可以通过 --discovery-token-unsafe-skip-ca-verification 参数禁用此验证。
这削弱了kubeadm 安全模型,因为其他节点可能会模仿 Kubernetes 控制平面节点。
TLS 引导机制也通过共享令牌驱动。
这用于向 Kubernetes 控制平面节点进行临时的身份验证,以提交本地创建的密钥对的证书签名请求(CSR)。
默认情况下,kubeadm 将设置 Kubernetes 控制平面节点自动批准这些签名请求。
这个令牌通过 --tls-bootstrap-token abcdef.1234567890abcdef 参数传入。
通常两个部分会使用相同的令牌。
在这种情况下可以使用 --token 参数,而不是单独指定每个令牌。
"join [api-server-endpoint]" 命令执行下列阶段:
preflight Run join pre-flight checks
control-plane-prepare Prepare the machine for serving a control plane
/download-certs [EXPERIMENTAL] Download certificates shared among control-plane nodes from the kubeadm-certs Secret
/certs Generate the certificates for the new control plane components
/kubeconfig Generate the kubeconfig for the new control plane components
/control-plane Generate the manifests for the new control plane components
kubelet-start Write kubelet settings, certificates and (re)start the kubelet
control-plane-join Join a machine as a control plane instance
/etcd Add a new local etcd member
/update-status Register the new control-plane node into the ClusterStatus maintained in the kubeadm-config ConfigMap
/mark-control-plane Mark a node as a control-plane
kubeadm join [api-server-endpoint] [flags]
选项
--apiserver-advertise-address string
如果该节点托管一个新的控制平面实例,则 API 服务器将公布其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--apiserver-bind-port int32 默认值: 6443
如果节点应该托管新的控制平面实例,则为 API 服务器要绑定的端口。
--certificate-key string
使用此密钥可以解密由 init 上传的证书 secret。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--cri-socket string
要连接的 CRI 套接字的路径。如果为空,则 kubeadm 将尝试自动检测此值;仅当安装了多个 CRI 或具有非标准 CRI 插槽时,才使用此选项。
--discovery-file string
对于基于文件的发现,给出用于加载集群信息的文件或者 URL。
--discovery-token string
对于基于令牌的发现,该令牌用于验证从 API 服务器获取的集群信息。
--discovery-token-ca-cert-hash stringSlice
对基于令牌的发现,验证根 CA 公钥是否与此哈希匹配 (格式: "<type>:<value>")。
--discovery-token-unsafe-skip-ca-verification
对于基于令牌的发现,允许在未关联 --discovery-token-ca-cert-hash 参数的情况下添加节点。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
-h, --help
join 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查列表;例如:'IsPrivilegedUser,Swap'。取值为 'all' 时将忽略检查中的所有错误。
--node-name string
指定节点的名称
--skip-phases stringSlice
要跳过的阶段列表
--tls-bootstrap-token string
指定在加入节点时用于临时通过 Kubernetes 控制平面进行身份验证的令牌。
--token string
如果未提供这些值,则将它们用于 discovery-token 令牌和 tls-bootstrap 令牌。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
join 工作流
kubeadm join
初始化 Kubernetes 工作节点并将其加入集群。
该操作过程包含下面几个步骤:
kubeadm 从 API 服务器下载必要的集群信息。
默认情况下,它使用引导令牌和 CA 密钥哈希来验证数据的真实性。
也可以通过文件或 URL 直接发现根 CA。
一旦知道集群信息,kubelet 就可以开始 TLS 引导过程。
TLS 引导程序使用共享令牌与 Kubernetes API 服务器进行临时的身份验证,以提交证书签名请求 (CSR);
默认情况下,控制平面自动对该 CSR 请求进行签名。
最后,kubeadm 配置本地 kubelet 使用分配给节点的确定标识连接到 API 服务器。
对于控制平面节点,执行额外的步骤:
从集群下载控制平面节点之间共享的证书(如果用户明确要求)。
生成控制平面组件清单、证书和 kubeconfig。
添加新的本地 etcd 成员。
将此节点添加到 kubeadm 集群的 ClusterStatus。
使用 kubeadm 的 join phase 命令
Kubeadm 允许你使用 kubeadm join phase
分阶段将节点加入集群。
要查看阶段和子阶段的有序列表,可以调用 kubeadm join --help
。
该列表将位于帮助屏幕的顶部,每个阶段旁边都有一个描述。
注意,通过调用 kubeadm join
,所有阶段和子阶段都将按照此确切顺序执行。
有些阶段具有唯一的标志,因此,如果要查看可用选项列表,请添加 --help
,例如:
kubeadm join phase kubelet-start --help
类似于 kubeadm init phase 命令,
kubeadm join phase
允许你使用 --skip-phases
标志跳过阶段列表。
例如:
sudo kubeadm join --skip-phases= preflight --config= config.yaml
发现要信任的集群 CA
Kubeadm 的发现有几个选项,每个选项都有安全性上的优缺点。
适合你的环境的正确方法取决于节点是如何准备的以及你对网络的安全性期望
和节点的生命周期特点。
带 CA 锁定模式的基于令牌的发现
这是 Kubernetes 1.8 及以上版本中的默认模式。
在这种模式下,kubeadm 下载集群配置(包括根CA)并使用令牌验证它,
并且会验证根 CA 的公钥与所提供的哈希是否匹配,
以及 API 服务器证书在根 CA 下是否有效。
CA 键哈希格式为 sha256:<hex_encoded_hash>
。
默认情况下,在 kubeadm init
最后打印的 kubeadm join
命令
或者 kubeadm token create --print-join-command
的输出信息中返回哈希值。
它使用标准格式 (请参考 RFC7469 )
并且也能通过第三方工具或者制备系统进行计算。
例如,使用 OpenSSL CLI:
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
kubeadm join
命令示例
对于工作节点:
kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef 1.2.3.4:6443
对于控制面节点:
kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef --control-plane 1.2.3.4:6443
如果使用 --upload-certs
调用 kubeadm init
命令,
你也可以对控制平面节点调用带 --certificate-key
参数的 join
命令,
将证书复制到该节点。
优势:
劣势:
CA 哈希通常在主节点被提供之前是不知道的,这使得构建使用 kubeadm 的自动化配置工具更加困难。
通过预先生成CA,你可以解除这个限制。
无 CA 锁定模式的基于令牌的发现
_这是 Kubernetes 1.7 和早期版本_中的默认设置;使用时要注意一些重要的补充说明。
此模式仅依赖于对称令牌来签名(HMAC-SHA256)发现信息,这些发现信息为主节点建立信任根。
在 Kubernetes 1.8 及以上版本中仍然可以使用 --discovery-token-unsafe-skip-ca-verification
参数,但是如果可能的话,你应该考虑使用一种其他模式。
kubeadm join
命令示例
kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-verification 1.2.3.4:6443
优势
劣势
如果攻击者能够通过某些漏洞窃取引导令牌,那么他们可以使用该令牌(连同网络级访问)
为其它处于引导过程中的节点提供假冒的主节点。
在你的环境中,这可能是一个适当的折衷方法,也可能不是。
基于 HTTPS 或文件发现
这种方案提供了一种带外方式在主节点和引导节点之间建立信任根。
如果使用 kubeadm 构建自动配置,请考虑使用此模式。
发现文件的格式为常规的 Kubernetes
kubeconfig 文件。
如果发现文件不包含凭据,则将使用 TLS 发现令牌。
kubeadm join
命令示例:
优势:
允许引导节点安全地发现主节点的信任根,即使网络或其他工作节点受到损害。
劣势:
要求你有某种方法将发现信息从主节点传送到引导节点。
例如,这可以通过云提供商或驱动工具实现。
该文件中的信息不是加密的,而是需要 HTTPS 或等效文件来保证其完整性。
确保你的安装更加安全
Kubeadm 的默认值可能不适用于所有人。
本节说明如何以牺牲可用性为代价来加强 kubeadm 安装。
关闭节点客户端证书的自动批准
默认情况下,Kubernetes 启用了 CSR 自动批准器,如果在身份验证时使用启动引导令牌,
它会批准对 kubelet 的任何客户端证书的请求。
如果不希望集群自动批准kubelet客户端证书,可以通过执行以下命令关闭它:
kubectl delete clusterrolebinding kubeadm:node-autoapprove-bootstrap
关闭后,kubeadm join
操作将会被阻塞,直到管理员已经手动批准了在途中的 CSR 才会继续:
输出类似于:
NAME AGE REQUESTOR CONDITION
node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 18s system:bootstrap:878f07 Pending
kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ
输出类似于:
certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved
输出类似于:
NAME AGE REQUESTOR CONDITION
node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 1m system:bootstrap:878f07 Approved,Issued
这迫使工作流只有在运行了 kubectl 证书批准后,kubeadm join 才能成功。
关闭对集群信息 ConfigMap 的公开访问
为了实现使用令牌作为唯一验证信息的加入工作流,默认情况下会公开带有验证主节点标识
所需数据的 ConfigMap。
虽然此 ConfigMap 中没有私有数据,但一些用户可能希望无论如何都关闭它。
这样做需要禁用 kubeadm join
工作流的 --discovery-token
参数。
以下是实现步骤:
从 API 服务器获取 cluster-info
文件:
kubectl -n kube-public get cm cluster-info -o yaml | grep "kubeconfig:" -A11 | grep "apiVersion" -A10 | sed "s/ //" | tee cluster-info.yaml
输出类似于:
apiVersion: v1
kind: Config
clusters:
- cluster:
certificate-authority-data: <ca-cert>
server: https://<ip>:<port>
name: ""
contexts: []
current-context: ""
preferences: {}
users: []
这些命令应该在执行 kubeadm init
之后、在kubeadm join
之前执行。
使用带有配置文件的 kubeadm join
注意:
配置文件目前是 alpha 功能,在将来的版本中可能会变动。
可以用配置文件替代命令行参数的方法配置 kubeadm join
,一些高级功能也只有在使用配置文件时才可选用。
该文件通过 --config
参数来传递,并且文件中必须包含 JoinConfiguration
结构。
在某些情况下,不允许将 --config
与其他标志混合使用。
使用 kubeadm config print
命令可以打印默认配置。
如果你的配置没有使用最新版本,
推荐 使用 kubeadm config migrate
命令转换。
有关配置的字段和用法的更多信息,你可以导航到我们的 API 参考页
并从[列表]中选择一个版本(https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories )。
接下来
8.1.4 - kubeadm upgrade
kubeadm upgrade
是一个对用户友好的命令,它将复杂的升级逻辑包装在一个命令后面,支持升级的规划和实际执行。
kubeadm upgrade 指南
本文档 概述
使用 kubeadm 执行升级的步骤。
与 kubeadm 旧版本相关的文档,请参阅 Kubernetes 网站的旧版文档。
你可以使用 kubeadm upgrade diff
来查看将应用于静态 Pod 清单的更改。
在 Kubernetes v1.15.0 和更高版本中,kubeadm upgrade apply
和 kubeadm upgrade node
也将自动续订该节点上的 kubeadm 托管证书,包括存储在 kubeconfig 文件中的证书。
要选择退出,可以传递参数 --certificate-renewal=false
。
有关证书续订的更多详细信息请参见证书管理文档 。
说明:
kubeadm upgrade apply
和 kubeadm upgrade plan
命令都具有遗留的 --config
标志,
可以在执行特定控制平面节点的规划或升级时重新配置集群。
请注意,升级工作流不是为这种情况而设计的,并且有意外结果的报告。
kubeadm upgrade plan
概述
检查可升级到哪些版本,并验证您当前的集群是否可升级。 要跳过互联网检查,请传递可选的 [version] 参数
kubeadm upgrade plan [version] [flags]
选项
--allow-experimental-upgrades
显示不稳定版本的 Kubernetes 作为升级替代方案,并允许升级到 Kubernetes 的 Alpha/Beta/发行候选版本。
--allow-release-candidate-upgrades
显示 Kubernetes 的发行候选版本作为升级选择,并允许升级到 Kubernetes 的发行候选版本。
--config string
配置文件的路径。
--feature-gates string
一组描述各种特征特性门控的键值对。选项有:IPv6DualStack=true|false (ALPHA - default=false) PublicKeysECDSA=true|false (ALPHA - default=false)
-h, --help
帮助
--ignore-preflight-errors stringSlice
检查清单,其错误将显示为警告。 例如:“IsPrivilegedUser,Swap”。 值 “all” 忽略所有检查的错误。
--kubeconfig string Default: "/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。 如果标志为未设置,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--print-config
指定是否打印将在升级中使用的配置文件。
从父命令继承的选项
--rootfs string
[EXPERIMENTAL] “真实”主机根文件系统的路径。
kubeadm upgrade apply
概要
将 Kubernetes 集群升级到指定版本
kubeadm upgrade apply [version]
选项
--allow-experimental-upgrades
显示 Kubernetes 的不稳定版本作为升级替代方案,并允许升级到 Kubernetes 的 alpha/beta 或 RC 版本。
--allow-release-candidate-upgrades
显示 Kubernetes 的候选版本作为升级替代方案,并允许升级到 Kubernetes 的 RC 版本。
--certificate-renewal Default: true
执行升级期间更改的组件所使用的证书的更新。
--config string
kubeadm 配置文件的路径。
--dry-run
不要更改任何状态,只输出要执行的操作。
--etcd-upgrade 默认值: true
执行 etcd 的升级。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
--feature-gates string
一组键值对,用于描述各种功能。选项包括:
IPv6DualStack=true|false (ALPHA - 默认=false)
PublicKeysECDSA=true|false (ALPHA - 默认=false)
-f, --force
强制升级,但可能无法满足某些要求。这也意味着非交互模式。
-h, --help
apply 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查列表;例如:'IsPrivilegedUser,Swap'。取值为 'all' 时将忽略检查中的所有错误。
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置标志,则在相关目录下搜索以查找现有 kubeconfig 文件。
--print-config
指定是否应打印将在升级中使用的配置文件。
-y, --yes
执行升级,不提示确认(非交互模式)。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
kubeadm upgrade diff
概述
显示哪些差异将被应用于现有的静态 pod 资源清单。参考: kubeadm upgrade apply --dry-run
kubeadm upgrade diff [version] [flags]
选项
--api-server-manifest string 默认值:"/etc/kubernetes/manifests/kube-apiserver.yaml"
API服务器清单的路径
--config string
kubeadm 配置文件的路径
-c, --context-lines int 默认值:3
差异中有多少行上下文
--controller-manager-manifest string 默认值: "/etc/kubernetes/manifests/kube-controller-manager.yaml"
控制器清单的路径
-h, --help
帮助
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件,如果标志是未设置,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--scheduler-manifest string 默认值:"/etc/kubernetes/manifests/kube-scheduler.yaml"
调度程序清单的路径
从父命令继承的选项
--rootfs string
[EXPERIMENTAL] “真实”主机根文件系统的路径。
kubeadm upgrade node
概要
升级集群中某个节点的命令
"node" 命令执行以下阶段:
preflight 执行节点升级前检查
control-plane 如果存在的话,升级部署在该节点上的管理面实例
kubelet-config 更新该节点上的 kubelet 配置
kubeadm upgrade node [flags]
选项
--certificate-renewal
对升级期间变化的组件所使用的证书执行更新。
--dry-run
不更改任何状态,只输出将要执行的操作。
--etcd-upgrade 默认值: true
执行 etcd 的升级。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
-h, --help
node 操作的帮助命令
--kubeconfig string 默认值: "/etc/kubernetes/admin.conf"
用于与集群交互的 kubeconfig 文件。如果参数未指定,将从一系列标准位置检索存在的 kubeconfig 文件。
--kubelet-version string
升级后 *期望的* kubelet 配置版本。如未指定,将使用 kubeadm-config ConfigMap 中的 KubernetesVersion
--skip-phases stringSlice
要跳过的阶段的列表
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
接下来
如果你使用 kubeadm v1.7.x 或更低版本初始化集群,则可以参考
kubeadm 配置
配置集群用于 kubeadm upgrade
。
8.1.5 - kubeadm config
在 kubeadm init
执行期间,kubeadm 将 ClusterConfiguration
对象上传
到你的集群的 kube-system
名字空间下名为 kubeadm-config
的 ConfigMap 对象中。
然后在 kubeadm join
、kubeadm reset
和 kubeadm upgrade
执行期间读取此配置。
要查看此 ConfigMap,请调用 kubeadm config view
。
你可以使用 kubeadm config print
命令打印默认配置,
并使用 kubeadm config migrate
命令将旧版本的配置转化成新版本。
kubeadm config images list
和 kubeadm config images pull
命令可以用来列出并拉取 kubeadm 所需的镜像。
更多信息请浏览使用带配置文件的 kubeadm init
或使用带配置文件的 kubeadm join .
你也可以在使用 kubeadm init
命令时配置若干 kubelet 配置选项。
这些选项对于集群中所有节点而言都是相同的。
参阅使用 kubeadm 来配置集群中的各个 kubelet
了解详细信息。
在 Kubernetes v1.13.0 及更高版本中,要列出/拉取 kube-dns 镜像而不是 CoreDNS 镜像,
必须使用这里
所描述的 --config
方法。
kubeadm config upload from-file
kubeadm config print
打印配置
概要
此命令打印子命令所提供的配置信息。
相关细节可参阅 https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2
kubeadm config print [flags]
选项
从父命令继承而来的选项
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如此标志未设置,将在一组标准位置中搜索现有的kubeconfig 文件。
--rootfs string
[试验性] 指向“真实”宿主根文件系统的路径。
kubeadm config print init-defaults
概要
此命令打印对象,例如用于 'kubeadm init' 的默认 init 配置对象。
请注意,Bootstrap Token 字段之类的敏感值已替换为 {"abcdef.0123456789abcdef" "" "nil" <nil> [] []} 之类的占位符值以通过验证,但不执行创建令牌的实际计算。
kubeadm config print init-defaults [flags]
选项
--component-configs stringSlice
组件配置 API 对象的逗号分隔列表,打印其默认值。可用值:[KubeProxyConfiguration KubeletConfiguration]。如果未设置此参数,则不会打印任何组件配置。
-h, --help
init-defaults 操作的帮助命令
从父命令继承的选项
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm config print join-defaults
概要
此命令打印对象,例如用于 'kubeadm join' 的默认 join 配置对象。
请注意,诸如启动引导令牌字段之类的敏感值已替换为 {"abcdef.0123456789abcdef" "" "nil" <nil> [] []}
之类的占位符值以通过验证,但不执行创建令牌的实际计算。
kubeadm config print join-defaults [flags]
选项
--component-configs stringSlice
组件配置 API 对象的逗号分隔列表,打印其默认值。可用值:[KubeProxyConfiguration KubeletConfiguration]。如果未设置此参数,则不会打印任何组件配置。
-h, --help
join-defaults 操作的帮助命令
从父命令继承的选项
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm config migrate
概要
此命令允许您在 CLI 工具中将本地旧版本的配置对象转换为最新支持的版本,而无需变更集群中的任何内容。在此版本的 kubeadm 中,支持以下 API 版本:
因此,无论您在此处传递 --old-config 参数的版本是什么,当写入到 stdout 或 --new-config (如果已指定)时,
都会读取、反序列化、默认、转换、验证和重新序列化 API 对象。
换句话说,如果您将此文件传递给 "kubeadm init",则该命令的输出就是 kubeadm 实际上在内部读取的内容。
kubeadm config migrate [flags]
选项
-h, --help
migrate 操作的帮助信息
--new-config string
使用新的 API 版本生成的 kubeadm 配置文件的路径。这个路径是可选的。如果没有指定,输出将被写到 stdout。
--old-config string
使用旧 API 版本且应转换的 kubeadm 配置文件的路径。此参数是必需的。
从父命令继承的选项
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 kubeconfig 文件。如果未设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 kubeconfig 文件。
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm config images list
概要
打印 kubeadm 要使用的镜像列表。配置文件用于自定义任何镜像或镜像存储库。
kubeadm config images list [flags]
选项
--allow-missing-template-keys 默认值:true
如果设置为 true,则在模板中缺少字段或哈希表的键时忽略模板中的任何错误。
仅适用于 golang 和 jsonpath 输出格式。
-o, --experimental-output string 默认值:"text"
输出格式:text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file 其中之一
--config string
kubeadm 配置文件的路径。
--feature-gates string
一组键值对(key=value),用于描述各种特征。选项是:
Auditing=true|false (ALPHA - 默认=false)
CoreDNS=true|false (默认=true)
DynamicKubeletConfig=true|false (BETA - 默认=false)
-h, --help
list 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择要从中拉取控制平面镜像的容器仓库
--kubernetes-version string 默认值:"stable-1"
为控制平面选择一个特定的 Kubernetes 版本
从父命令继承的选项
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 kubeconfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 kubeconfig 文件。
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm config images pull
概要
拉取 kubeadm 使用的镜像。
kubeadm config images pull [flags]
选项
--config string
kubeadm 配置文件的路径。
--cri-socket string
要连接的 CRI 套接字的路径。如果为空,则 kubeadm 将尝试自动检测此值;仅当安装了多个 CRI 或具有非标准 CRI 插槽时,才使用此选项。
--feature-gates string
一系列键值对(key=value),用于描述各种特征。可选项是: IPv6DualStack=true|false (ALPHA - 默认值=false)
-h, --help
pull 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择用于拉取控制平面镜像的容器仓库
--kubernetes-version string 默认值:"stable-1"
为控制平面选择一个特定的 Kubernetes 版本。
从父命令继承的选项
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 kubeconfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 kubeconfig 文件。
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
接下来
8.1.6 - kubeadm reset
该命令尽力还原由 kubeadm init
或 kubeadm join
所做的更改。
概要
尽最大努力还原通过 'kubeadm init' 或者 'kubeadm join' 操作对主机所做的更改
"reset" 命令执行以下阶段:
preflight Run reset pre-flight checks
update-cluster-status Remove this node from the ClusterStatus object.
remove-etcd-member Remove a local etcd member.
cleanup-node Run cleanup node.
kubeadm reset [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的目录路径。如果已指定,则需要清空此目录。
--cri-socket string
要连接的 CRI 套接字的路径。如果为空,则 kubeadm 将尝试自动检测此值;仅当安装了多个CRI 或具有非标准 CRI 插槽时,才使用此选项。
-f, --force
在不提示确认的情况下重置节点。
-h, --help
reset 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查列表;例如:'IsPrivilegedUser,Swap'。取值为 'all' 时将忽略检查中的所有错误。
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该标志,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--skip-phases stringSlice
要跳过的阶段列表
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
Reset 工作流程
kubeadm reset
负责从使用 kubeadm init
或 kubeadm join
命令创建的文件中清除节点本地文件系统。对于控制平面节点,reset
还从 etcd 集群中删除该节点的本地 etcd 堆成员,还从 kubeadm ClusterStatus
对象中删除该节点的信息。
ClusterStatus
是一个 kubeadm 管理的 Kubernetes API 对象,该对象包含 kube-apiserver 端点列表。
kubeadm reset phase
可用于执行上述工作流程的各个阶段。
要跳过阶段列表,你可以使用 --skip-phases
参数,该参数的工作方式类似于 kubeadm join
和 kubeadm init
阶段运行器。
外部 etcd 清理
如果使用了外部 etcd,kubeadm reset
将不会删除任何 etcd 中的数据。这意味着,如果再次使用相同的 etcd 端点运行 kubeadm init
,你将看到先前集群的状态。
要清理 etcd 中的数据,建议你使用 etcdctl 这样的客户端,例如:
更多详情请参考 etcd 文档 。
接下来
8.1.7 - kubeadm token
如使用引导令牌进行身份验证 所描述的,引导令牌用于在即将加入集群的节点和主节点间建立双向认证。
kubeadm init
创建了一个有效期为 24 小时的令牌,下面的命令允许你管理令牌,也可以创建和管理新的令牌。
kubeadm token create
概要
这个命令将为你创建一个引导令牌。
您可以设置此令牌的用途,"有效时间" 和可选的人性化的描述。
这里的 [token] 是指将要生成的实际令牌。
该令牌应该是一个通过安全机制生成的随机令牌,形式为 "[a-z0-9]{6}.[a-z0-9]{16}"。
如果没有给出 [token],kubeadm 将生成一个随机令牌。
kubeadm token create [token]
选项
--config string
kubeadm 配置文件的路径。
--description string
针对令牌用途的人性化的描述。
--groups stringSlice 默认值:[system:bootstrappers:kubeadm:default-node-token]
此令牌用于身份验证时将进行身份验证的其他组。必须匹配 "\\Asystem:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]\\z"
-h, --help
create 操作的帮助命令
--print-join-command
不仅仅打印令牌,而是打印使用令牌加入集群所需的完整 'kubeadm join' 参数。
--ttl duration 默认值:24h0m0s
令牌有效时间,超过该时间令牌被自动删除。(例如: 1s, 2m, 3h)。如果设置为 '0',令牌将永远不过期。
--usages stringSlice 默认值:[signing,authentication]
描述可以使用此令牌的方式。你可以多次使用 `--usages` 或者提供一个以逗号分隔的选项列表。合法选项有: [signing,authentication]
从父命令继承的选项
--dry-run
是否启用 `dry-run` 运行模式
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
kubeadm token delete
概要
这个命令将为你删除指定的引导令牌列表。
[token-value]
是要删除的 "[a-z0-9]{6}.[a-z0-9]{16}" 形式的完整令牌或者是 "[a-z0-9]{6}" 形式的的令牌 ID。
kubeadm token delete [token-value] ...
选项
-h, --help
delete 操作的帮助命令
从父命令继承的选项
--dry-run
是否启用 `dry-run` 运行模式
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
kubeadm token generate
概要
此命令将打印一个随机生成的可以被 "init" 和 "join" 命令使用的引导令牌。
您不必使用此命令来生成令牌。你可以自己设定,只要格式符合 "[a-z0-9]{6}.[a-z0-9]{16}"。这个命令提供是为了方便生成规定格式的令牌。
您也可以使用 "kubeadm init" 并且不指定令牌,该命令会生成一个令牌并打印出来。
kubeadm token generate [flags]
选项
-h, --help
generate 操作的帮助命令
从父命令继承的选项
--dry-run
是否启用 `dry-run` 运行模式
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
kubeadm token list
概要
此命令将为您列出所有的引导令牌。
kubeadm token list [flags]
选项
--allow-missing-template-keys 默认值:true
如果设置为 true,则在模板中缺少字段或哈希表的键时忽略模板中的任何错误。
仅适用于 golang 和 jsonpath 输出格式。
-o, --experimental-output string 默认值:"text"
输出格式:text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file 其中之一
-h, --help
list 操作的帮助命令
从父命令继承的选项
--dry-run
是否启用 `dry-run` 模式
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 kubeconfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 kubeconfig 文件。
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
接下来
8.1.8 - kubeadm version
此命令用来输出 kubeadm 的版本。
概要
打印 kubeadm 的版本
kubeadm version [flags]
选项
-h, --help
version 操作的帮助命令
-o, --output string
输出格式;可用的选项有 'yaml', 'json' 和 'short'
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
8.1.9 - kubeadm alpha
注意:
kubeadm alpha
提供了一组可用于收集社区反馈的预览性质功能。
请试用这些功能并给我们提供反馈!
目前在 kubeadm alpha
之下没有试验性质的命令。
接下来
8.1.10 - kubeadm certs
kubeadm certs
提供管理证书的工具。关于如何使用这些命令的细节,可参见
使用 kubeadm 管理证书 。
kubeadm certs
用来操作 Kubernetes 证书的一组命令。
概要
与处理 kubernetes 证书相关的命令
选项
继承于父命令的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
kubeadm certs renew
你可以使用 all
子命令来续订所有 Kubernetes 证书,也可以选择性地续订部分证书。
更多的相关细节,可参见
手动续订证书 。
概要
此命令并非设计用来单独运行。请参阅可用子命令列表。
kubeadm certs renew [flags]
选项
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
续订运行控制平面所需的所有已知证书。续订是无条件进行的,与到期日期无关。续订也可以单独运行以进行更多控制。
kubeadm certs renew all [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
输出 CSR 和私钥的路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
all 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
续订 kubeconfig 文件中嵌入的证书,供管理员 和 kubeadm 自身使用。
无论证书的到期日期如何,续订都是无条件进行的;SAN 等额外属性将基于现有文件/证书,因此无需重新提供它们。
默认情况下,续订会尝试使用由 kubeadm 管理的本地 PKI 中的证书机构;作为替代方案,
也可以使用 K8s 证书 API 进行证书续订,或者(作为最后一种选择)生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防证书文件在其他地方使用。
kubeadm certs renew admin.conf [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
CSR 和私钥的输出路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
admin.conf 子操作的帮助命令
--kubeconfig string Default: "/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
续订 apiserver 用于访问 etcd 的证书。
无论证书的到期日期如何,续订都会无条件地进行;SAN 等额外属性将基于现有文件/证书,因此无需重新提供它们。
默认情况下,续订尝试使用在 kubeadm 所管理的本地 PKI 中的证书颁发机构;作为替代方案,
可以使用 K8s 证书 API 进行证书更新,或者作为最后一个选择来生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防文件在其他地方使用。
kubeadm certs renew apiserver-etcd-client [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
输出 CSR 和私钥的路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
apiserver-etcd-client 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
续订 apiserver 用于连接 kubelet 的证书。
无论证书的到期日期如何,续订都会无条件地进行;SAN 等额外属性将基于现有文件/证书,因此无需重新提供它们。
默认情况下,续订尝试使用位于 kubeadm 所管理的本地 PKI 中的证书颁发机构;作为替代方案,
也可能调用 K8s 证书 API 进行证书更新;亦或者,作为最后一个选择,生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防文件在其他地方使用。
kubeadm certs renew apiserver-kubelet-client [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
输出 CSR 和私钥的路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
apiserver-kubelet-client 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
续订用于提供 Kubernetes API 的证书。
无论证书的到期日期如何,续订都会无条件地进行;SAN 等额外属性将基于现有文件/证书,因此无需重新提供它们。
默认情况下,续订尝试在 kubeadm 管理的本地 PKI 中使用证书颁发机构;作为替代方案,
可以使用 K8s 证书 API 进行证书更新,或者作为最后一个选择来生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防文件在其他地方使用。
kubeadm certs renew apiserver [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
CSR 和私钥的输出路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
apiserver 子操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
续订 kubeconfig 文件中嵌入的证书,以供控制器管理器(Controller Manager)使用。
续订无条件地进行,与证书的到期日期无关;SAN 等额外属性将基于现有的文件/证书,因此无需重新提供它们。
默认情况下,续订会尝试使用 kubeadm 管理的本地 PKI 中的证书颁发机构;作为替代方案,
可以使用 K8s 证书 API 进行证书续订;亦或者,作为最后一种选择,生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防文件在其他地方使用。
kubeadm alpha renew controller-manager.conf [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
CSR 和私钥的输出路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
controller-manager.conf 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
续订存活态探针的证书,用于对 etcd 执行健康检查。
无论证书的到期日期如何,续订都是无条件进行的;SAN 等额外属性将基于现有文件/证书,因此无需重新提供它们。
默认情况下,续订会尝试使用由 kubeadm 管理的本地 PKI 中的证书机构;作为替代方案,
也可以使用 K8s certificate API 进行证书续订,或者(作为最后一种选择)生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防证书文件在其他地方使用。
kubeadm certs renew etcd-healthcheck-client [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
CSR 和私钥的输出路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
etcd-healthcheck-client 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
续订 etcd 节点间用来相互通信的证书。
无论证书的到期日期如何,续订都是无条件进行的;SAN 等额外属性将基于现有文件/证书,因此无需重新提供它们。
默认情况下,续订会尝试使用由 kubeadm 管理的本地 PKI 中的证书机构;
作为替代方案,也可以使用 K8s certificate API 进行证书续订,或者(作为最后一种选择)生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防证书文件在其他地方使用。
kubeadm certs renew etcd-peer [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
CSR 和私钥的输出路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
etcd-peer 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
续订用于提供 etcd 服务的证书。
续订无条件地进行,与证书的到期日期无关;SAN 等额外属性将基于现有的文件/证书,因此无需重新提供它们。
默认情况下,续订会尝试在 kubeadm 管理的本地 PKI 中使用证书颁发机构;作为替代方案,
可以使用 K8s 证书 API 进行证书续订,或者作为最后一种选择来生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防文件在其他地方使用。
kubeadm certs renew etcd-server [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
CSR 和私钥的输出路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
etcd-server 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
为前端代理客户端续订证书。
无论证书的到期日期如何,续订都会无条件地进行;SAN 等额外属性将基于现有文件/证书,因此无需重新提供它们。
默认情况下,续订尝试使用位于 kubeadm 所管理的本地 PKI 中的证书颁发机构;作为替代方案,
也可以使用 K8s 证书 API 进行证书续订;亦或者,作为最后一种方案,生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防文件在其他地方使用。
kubeadm certs renew front-proxy-client [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
输出 CSR 和私钥的路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
front-proxy-client 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
续订 kubeconfig 文件中嵌入的证书,以供调度管理器使用。
续订无条件地进行,与证书的到期日期无关;SAN 等额外属性将基于现有的文件/证书,因此无需重新提供它们。
默认情况下,续订会尝试使用在 kubeadm 所管理的本地 PKI 中的证书颁发机构;作为替代方案,
也可以使用 K8s 证书 API 进行证书续订;亦或者,作为最后一种选择,生成 CSR 请求。
续订后,为了使更改生效,需要重新启动控制平面组件,并最终重新分发更新的证书,以防文件在其他地方使用。
kubeadm certs renew scheduler.conf [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存证书的路径。
--config string
kubeadm 配置文件的路径。
--csr-dir string
CSR 和私钥的输出路径
--csr-only
创建 CSR 而不是生成证书
-h, --help
scheduler.conf 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。
如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--use-api
使用 Kubernetes 证书 API 续订证书
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm certs certificate-key
此命令可用来生成一个新的控制面证书密钥。密钥可以作为 --certificate-key
标志的取值传递给 kubeadm init
和 kubeadm join
命令,从而在添加新的控制面节点时能够自动完成证书复制。
概要
该命令将打印出可以与 "init" 命令一起使用的安全的随机生成的证书密钥。
你也可以使用 kubeadm init --upload-certs
而无需指定证书密钥;
命令将为你生成并打印一个证书密钥。
kubeadm certs certificate-key [flags]
选项
-h, --help
certificate-key 操作的帮助命令
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm certs check-expiration
此命令检查 kubeadm 所管理的本地 PKI 中的证书是否以及何时过期。
更多的相关细节,可参见
检查证书过期 。
概要
检查 kubeadm 管理的本地 PKI 中证书的到期时间。
kubeadm certs check-expiration [flags]
选项
--cert-dir string 默认值: "/etc/kubernetes/pki"
保存证书的路径
--config string
kubeadm 配置文件的路径
-h, --help
check-expiration 的帮助命令
继承于父命令的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
kubeadm certs generate-csr
此命令可用来为所有控制面证书和 kubeconfig 文件生成密钥和 CSR(签名请求)。
用户可以根据自身需要选择 CA 为 CSR 签名。
为运行控制平面所需的所有证书生成密钥和证书签名请求(CSR)。该命令会生成部分 kubeconfig 文件,
其中 "users > user > client-key-data" 字段包含私钥数据,并为每个 kubeconfig
文件创建一个随附的 ".csr" 文件。
此命令设计用于
Kubeadm 外部 CA 模式 。
它生成你可以提交给外部证书颁发机构进行签名的 CSR。
应使用 ".crt" 作为文件扩展名将 PEM 编码的签名证书与密钥文件一起保存。
或者,对于 kubeconfig 文件,PEM 编码的签名证书应使用 base64 编码,
并添加到 "users > user > client-certificate-data" 字段。
kubeadm certs generate-csr [flags]
示例
# 以下命令将为所有控制平面证书和 kubeconfig 文件生成密钥和 CSR :
kubeadm certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki
选项
--cert-dir string
保存证书的路径
--config string
kubeadm 配置文件的路径。
-h, --help
generate-csr 命令的帮助
--kubeconfig-dir string 默认值:"/etc/kubernetes"
保存 kubeconfig 文件的路径。
继承于父命令的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
接下来
8.1.11 - kubeadm init phase
kubeadm init phase
能确保调用引导过程的原子步骤。
因此,如果希望自定义应用,则可以让 kubeadm 做一些工作,然后填补空白。
kubeadm init phase
与 kubeadm init 工作流
一致,后台都使用相同的代码。
kubeadm init phase preflight
使用此命令可以在控制平面节点上执行启动前检查。
概要
运行 kubeadm init 前的启动检查。
kubeadm init phase preflight [flags]
案例
# 使用配置文件对 kubeadm init 进行启动检查。
kubeadm init phase preflight --config kubeadm-config.yml
选项
--config string
kubeadm 配置文件的路径。
-h, --help
preflight 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查列表:例如:'IsPrivilegedUser,Swap'。取值为 'all' 时将忽略检查中的所有错误。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm init phase kubelet-start
此阶段将检查 kubelet 配置文件和环境文件,然后启动 kubelet。
概要
使用 kubelet 配置文件编写一个文件,并使用特定节点的 kubelet 设置编写一个环境文件,然后(重新)启动 kubelet。
kubeadm init phase kubelet-start [flags]
示例
# 从 InitConfiguration 文件中写入带有 kubelet 参数的动态环境文件。
kubeadm init phase kubelet-start --config config.yaml
选项
--config string
kubeadm 配置文件的路径。
--cri-socket string
连接到 CRI 套接字的路径。如果为空,则 kubeadm 将尝试自动检测该值;仅当安装了多个 CRI 或具有非标准 CRI 套接字时,才使用此选项。
-h, --help
kubelet-start 操作的帮助命令
--node-name string
指定节点名称。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm init phase certs
该阶段可用于创建 kubeadm 所需的所有证书。
概要
此命令并非设计用来单独运行。请参阅可用子命令列表。
kubeadm init phase certs [flags]
选项
从父指令中继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成所有证书
kubeadm init phase certs all [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,将使用默认网络接口。
--apiserver-cert-extra-sans stringSlice
用于 API 服务器服务证书的可选额外替代名称(SAN)。可以同时使用 IP 地址和 DNS 名称。
--cert-dir string 默认值:"/etc/kubernetes/pki"
证书的存储路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
all 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
--service-cidr string 默认值:"10.96.0.0/12"
VIP 服务使用其它的 IP 地址范围。
--service-dns-domain string 默认值:"cluster.local"
服务使用其它的域名,例如:"myorg.internal"。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成自签名的 Kubernetes CA 以提供其他 Kubernetes 组件的身份,并将其保存到 ca.cert 和 ca.key 文件中。
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 Alpha 功能。
kubeadm init phase certs ca [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
证书的存储路径。
--config string
kubeadm 配置文件的路径。
-h, --help
ca 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成用于服务 Kubernetes API 的证书,并将其保存到 apiserver.cert 和 apiserver.key 文件中。
默认 SAN 是 kubernetes、kubernetes.default、kubernetes.default.svc、kubernetes.default.svc.cluster.local、10.96.0.1、127.0.0.1。
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 Alpha 功能。
kubeadm init phase certs apiserver [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则使用默认的网络接口。
--apiserver-cert-extra-sans stringSlice
用于 API Server 服务证书的可选附加主体备用名称(SAN)。可以是 IP 地址和 DNS 名称。
--cert-dir string 默认值:"/etc/kubernetes/pki"
证书的存储路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
apiserver 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
--service-cidr string 默认值:"10.96.0.0/12"
指定服务 VIP 可使用的其他 IP 地址段。
--service-dns-domain string 默认值:"cluster.local"
为服务使用其他域名,例如 "myorg.internal"。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成供 API 服务器连接 kubelet 的证书,并将其保存到 apiserver-kubelet-client.cert 和 apiserver-kubelet-client.key 文件中。
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 Alpha 功能。
kubeadm init phase certs apiserver-kubelet-client [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件路径。
-h, --help
apiserver-kubelet-client 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 指向宿主机上的 '实际' 根文件系统的路径。
概要
生成自签名 CA 来提供前端代理的身份,并将其保存到 front-proxy-ca.cert 和 front-proxy-ca.key 文件中。
如果两个文件都已存在,kubeadm 将跳过生成步骤并将使用现有文件。
Alpha 免责声明:此命令目前是 alpha 阶段。
kubeadm init phase certs front-proxy-ca [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
-h, --help
front-proxy-ca 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
为前端代理客户端生成证书,并将其保存到 front-proxy-client.cert 和 front-proxy-client.key 文件中。
如果两个文件都已存在,kubeadm 将跳过生成步骤并将使用现有文件。
Alpha 免责声明:此命令目前是 alpha 阶段。
kubeadm init phase certs front-proxy-client [flags]
选项
--cert-dir string 默认:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
-h, --help
front-proxy-client 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成用于为 etcd 设置身份的自签名 CA,并将其保存到 etcd/ca.cert 和 etcd/ca.key 文件中。
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 Alpha 功能。
kubeadm init phase certs etcd-ca [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
证书的存储路径。
--config string
kubeadm 配置文件的路径。
-h, --help
etcd-ca 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成用于提供 etcd 服务的证书,并将其保存到 etcd/server.cert 和 etcd/server.key 文件中。
默认 SAN 为 localhost、127.0.0.1、127.0.0.1、:: 1
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 alpha 功能。
kubeadm init phase certs etcd-server [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
-h, --help
etcd-server 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成 etcd 节点相互通信的证书,并将其保存到 etcd/peer.cert 和 etcd/peer.key 文件中。
默认 SAN 为 localhost、127.0.0.1、127.0.0.1、:: 1
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 alpha 功能。
kubeadm init phase certs etcd-peer [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
-h, --help
etcd-peer 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成用于 etcd 健康检查的活跃性探针的证书,并将其保存到 healthcheck-client.cert 和 etcd/healthcheck-client.key 文件中。
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 alpha 功能。
kubeadm init phase certs etcd-healthcheck-client [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
证书存储的路径。
--config string
kubeadm 配置文件的路径。
-h, --help
etcd-healthcheck-client 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成 apiserver 用于访问 etcd 的证书,并将其保存到 apiserver-etcd-client.cert 和 apiserver-etcd-client.key 文件中。
如果两个文件都已存在,则 kubeadm 将跳过生成步骤,使用现有文件。
Alpha 免责声明:此命令当前为 Alpha 功能。
kubeadm init phase certs apiserver-etcd-client [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
证书的存储路径。
--config string
kubeadm 配置文件的路径。
-h, --help
apiserver-etcd-client 操作的帮助命令
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成用于签名 service account 令牌的私钥及其公钥,并将其保存到 sa.key 和 sa.pub 文件中。如果两个文件都已存在,则 kubeadm 会跳过生成步骤,而将使用现有文件。
Alpha 免责声明:此命令当前为 alpha 阶段。
kubeadm init phase certs sa [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
-h, --help
sa 操作的帮助命令
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm init phase kubeconfig
可以通过调用 all
子命令来创建所有必需的 kubeconfig 文件,或者分别调用它们。
概要
此命令并非设计用来单独运行。请阅读可用子命令列表。
kubeadm init phase kubeconfig [flags]
选项
-h, --help
kubeconfig 操作的帮助命令
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成所有 kubeconfig 文件
kubeadm init phase kubeconfig all [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果没有设置,将使用默认的网络接口。
--apiserver-bind-port int32 默认值:6443
要绑定到 API 服务器的端口。
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
all 操作的帮助命令
--kubeconfig-dir string 默认值:"/etc/kubernetes"
kubeconfig 文件的保存路径。
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
--node-name string
指定节点名称。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
为管理员和 kubeadm 本身生成 kubeconfig 文件,并将其保存到 admin.conf 文件中。
kubeadm init phase kubeconfig admin [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则使用默认的网络接口。
--apiserver-bind-port int32 默认值:6443
要绑定到 API 服务器的端口。
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
admin 操作的帮助命令
--kubeconfig-dir string 默认值:"/etc/kubernetes"
kubeconfig 文件的保存路径。
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成 kubelet 要使用的 kubeconfig 文件,并将其保存到 kubelet.conf 文件。
请注意,该操作目的是仅 应用于引导集群。在控制平面启动之后,应该从 CSR API 请求所有 kubelet 凭据。
kubeadm init phase kubeconfig kubelet [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则使用默认的网络接口。
--apiserver-bind-port int32 默认值:6443
要绑定到 API 服务器的端口。
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
kubelet 操作的帮助命令
--kubeconfig-dir string 默认值:"/etc/kubernetes"
kubeconfig 文件的保存路径。
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
--node-name string
指定节点的名称。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成控制器管理器要使用的 kubeconfig 文件,并保存到 controller-manager.conf 文件中。
kubeadm init phase kubeconfig controller-manager [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则使用默认的网络接口。
--apiserver-bind-port int32 默认值:6443
要绑定到 API 服务器的端口。
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
controller-manager 操作的帮助命令
--kubeconfig-dir string 默认值:"/etc/kubernetes"
kubeconfig 文件的保存路径。
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs 字符串
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成调度器(scheduler)要使用的 kubeconfig 文件,并保存到 scheduler.conf 文件中。
kubeadm init phase kubeconfig scheduler [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则使用默认的网络接口。
--apiserver-bind-port int32 默认值:6443
要绑定到 API 服务器的端口。
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
scheduler 操作的帮助命令
--kubeconfig-dir string 默认值:"/etc/kubernetes"
kubeconfig 文件的保存路径。
--kubernetes-version string 默认值:"stable-1"
为控制平面指定特定的 Kubernetes 版本。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm init phase control-plane
使用此阶段,可以为控制平面组件创建所有必需的静态 Pod 文件。
概要
此命令并非设计用来单独运行。请参阅可用子命令列表。
kubeadm init phase control-plane [flags]
选项
-h, --help
control-plane 操作的帮助命令
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成所有的静态 Pod 清单文件
kubeadm init phase control-plane all [flags]
示例
# 为控制平面组件生成静态 Pod 清单文件,其功能等效于 kubeadm init 生成的文件。
kubeadm init phase control-plane all
# 使用从某配置文件中读取的选项为生成静态 Pod 清单文件。
kubeadm init phase control-plane all --config config.yaml
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,将使用默认的网络接口。
--apiserver-bind-port int32 默认值:6443
API 服务器要绑定的端口。
--apiserver-extra-args mapStringString
形式为 <flagname>=<value> 的一组额外参数,用来传递给 API 服务器,
或者覆盖其默认配置值
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面选择一个稳定的 IP 地址或者 DNS 名称。
--controller-manager-extra-args mapStringString
一组形式为 <flagname>=<value> 的额外参数,用来传递给控制管理器(Controller Manager)
或覆盖其默认设置值
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录。
例如,"kube-apiserver0+merge.yaml" 或者 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,分别与 kubectl
所支持的 patch 格式相匹配。默认的 "patchtype" 是 "strategic"。
"extension" 必须是 "json" 或 "yaml"。
"suffix" 是一个可选的字符串,用来确定按字母顺序排序时首先应用哪些 patch。
--feature-gates string
一组用来描述各种特性门控的键值(key=value)对。选项是:
IPv6DualStack=true|false (ALPHA - 默认=false)
PublicKeysECDSA=true|false (ALPHA - 默认=false)
-h, --help
all 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择用于拉取控制平面镜像的容器仓库
--kubernetes-version string 默认值:"stable-1"
为控制平面选择指定的 Kubernetes 版本。
--pod-network-cidr string
指定 Pod 网络的 IP 地址范围。如果设置了此标志,控制平面将自动地为每个节点分配 CIDR。
--scheduler-extra-args mapStringString
一组形式为 <flagname>=<value> 的额外参数,用来传递给调度器(Scheduler)
或覆盖其默认设置值
传递给调度器(scheduler)一组额外的参数或者以 <flagname>=<value> 形式覆盖其默认值。
--service-cidr string 默认值:"10.96.0.0/12"
为服务 VIP 选择 IP 地址范围。
从父指令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机的根文件系统的路径。
概要
生成 kube-apiserver 静态 Pod 清单
kubeadm init phase control-plane apiserver [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,将使用默认网络接口。
--apiserver-bind-port int32 默认值: 6443
要绑定到 API 服务器的端口。
--apiserver-extra-args mapStringString
一组 <flagname>=<value> 形式的额外参数,用来传递给 API 服务器
或者覆盖其默认参数配置
--cert-dir string 默认值:"/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
包含名为 "target[suffix][+patchtype].extension" 的文件的目录。
例如,"kube-apiserver0+merge.yaml" 或者 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,分别与 kubectl
所支持的 patch 格式相匹配。默认的 "patchtype" 是 "strategic"。
"extension" 必须是 "json" 或 "yaml"。
"suffix" 是一个可选的字符串,用来确定按字母顺序排序时首先应用哪些 patch。
--feature-gates string
一组键值对,用于描述各种功能特性的特性门控。选项是:
IPv6DualStack=true|false (ALPHA - 默认=false)
PublicKeysECDSA=true|false (ALPHA - 默认=false)
-h, --help
apiserver 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择要从中拉取控制平面镜像的容器仓库
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本
--service-cidr string 默认值:"10.96.0.0/12"
指定服务 VIP 使用 IP 地址的其他范围。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统路径。
概要
生成 kube-controller-manager 静态 Pod 清单
kubeadm init phase control-plane controller-manager [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--controller-manager-extra-args mapStringString
一组 <flagname>=< 形式的额外参数,传递给控制器管理器(Controller Manager)
或者覆盖其默认配置值
包含名为 "target[suffix][+patchtype].extension" 的文件的目录。
例如,"kube-apiserver0+merge.yaml" 或者 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,分别与 kubectl
所支持的 patch 格式相匹配。默认的 "patchtype" 是 "strategic"。
"extension" 必须是 "json" 或 "yaml"。
"suffix" 是一个可选的字符串,用来确定按字母顺序排序时首先应用哪些 patch。
-h, --help
controller-manager 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择要从中拉取控制平面镜像的容器仓库
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
--pod-network-cidr string
指定 Pod 网络的 IP 地址范围。如果设置,控制平面将自动为每个节点分配 CIDR。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
生成 kube-scheduler 静态 Pod 清单
kubeadm init phase control-plane scheduler [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录。
例如,"kube-apiserver0+merge.yaml" 或者 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,分别与 kubectl
所支持的 patch 格式相匹配。默认的 "patchtype" 是 "strategic"。
"extension" 必须是 "json" 或 "yaml"。
"suffix" 是一个可选的字符串,用来确定按字母顺序排序时首先应用哪些 patch。
-h, --help
scheduler 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择要从中拉取控制平面镜像的容器仓库
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
--scheduler-extra-args mapStringString
一组 <flagname>=<value> 形式的额外参数,用来传递给调度器
或者覆盖其默认参数配置
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm init phase etcd
根据静态 Pod 文件,使用以下阶段创建本地 etcd 实例。
概要
此命令并非设计用来单独运行。请参阅可用子命令列表。
kubeadm init phase etcd [flags]
选项
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
为本地单节点 etcd 实例生成静态 Pod 清单文件
kubeadm init phase etcd local [flags]
示例
# 为 etcd 生成静态 Pod 清单文件,其功能等效于 kubeadm init 生成的文件。
kubeadm init phase etcd local
# 使用从配置文件读取的选项为 etcd 生成静态 Pod 清单文件。
kubeadm init phase etcd local --config config.yaml
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的路径。
--config string
kubeadm 配置文件的路径。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
-h, --help
local 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择要从中拉取控制平面镜像的容器仓库
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm init phase upload-config
可以使用此命令将 kubeadm 配置文件上传到集群。或者使用
kubeadm config 。
概要
此命令并非设计用来单独运行。请参阅可用的子命令列表。
kubeadm init phase upload-config [flags]
选项
-h, --help
upload-config 操作的帮助命令
从父命令中继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
将所有配置上传到 ConfigMap
kubeadm init phase upload-config all [flags]
选项
--config string
kubeadm 配置文件的路径。
-h, --help
all 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
将 kubeadm ClusterConfiguration 上传到 kube-system 命名空间中名为 kubeadm-config 的 ConfigMap 中。
这样就可以正确配置系统组件,并在升级时提供无缝的用户体验。
另外,可以使用 kubeadm 配置。
kubeadm init phase upload-config kubeadm [flags]
示例
# 上传集群配置
kubeadm init phase upload-config --config=myConfig.yaml
选项
--config string
kubeadm 配置文件的路径。
-h, --help
kubeadm 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
将从 kubeadm InitConfiguration 对象提取的 kubelet 配置上传到集群中 kubelet-config-1.X 形式的
ConfigMap,其中 X 是当前(API 服务器)Kubernetes 版本的次要版本。
kubeadm init phase upload-config kubelet [flags]
示例
# 将 kubelet 配置从 kubeadm 配置文件上传到集群中的 ConfigMap。
kubeadm init phase upload-config kubelet --config kubeadm.yaml
选项
--config string
到 kubeadm 配置文件的路径。
-h, --help
kubelet 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该标签,则可以通过一组标准路径来寻找已有的 kubeconfig 文件。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm init phase upload-certs
使用以下阶段将控制平面证书上传到集群。默认情况下,证书和加密密钥会在两个小时后过期。
概要
此命令并非设计用来单独运行。请参阅可用子命令列表。
kubeadm init phase upload-certs [flags]
选项
--certificate-key string
用于加密 kubeadm-certs Secret 中的控制平面证书的密钥。
--config string
kubeadm 配置文件的路径。
-h, --help
upload-certs 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用来与集群通信的 kubeconfig 文件。
如果此标志未设置,则可以在一组标准的位置搜索现有的 kubeconfig 文件。
--skip-certificate-key-print
不要打印输出用于加密控制平面证书的密钥。
--upload-certs
将控制平面证书上传到 kubeadm-certs Secret。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm init phase mark-control-plane
使用以下阶段来给具有 node-role.kubernetes.io/master=""
键值对的节点
打标签(label)和记录污点(taint)。
概要
标记 Node 节点为控制平面节点
kubeadm init phase mark-control-plane [flags]
示例
# 将控制平面标签和污点应用于当前节点,其功能等效于 kubeadm init执行的操作。
kubeadm init phase mark-control-plane --config config.yml
# 将控制平面标签和污点应用于特定节点
kubeadm init phase mark-control-plane --node-name myNode
选项
--config string
kubeadm 配置文件的路径。
-h, --help
mark-control-plane 操作的帮助命令
--node-name string
指定节点名称。
从父命令继承的选项
--rootfs 字符串
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm init phase bootstrap-token
使用以下阶段来配置引导令牌。
概要
启动引导令牌(bootstrap token)用于在即将加入集群的节点和控制平面节点之间建立双向信任。
该命令使启动引导令牌(bootstrap token)所需的所有配置生效,然后创建初始令牌。
kubeadm init phase bootstrap-token [flags]
示例
# 进行所有引导令牌配置,并创建一个初始令牌,功能上与 kubeadm init 生成的令牌等效。
kubeadm init phase bootstrap-token
选项
--config string
kubeadm 配置文件的路径。
-h, --help
bootstrap-token 操作的帮助命令
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
用于和集群通信的 kubeconfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 kubeconfig 文件。
--skip-token-print
跳过打印 'kubeadm init' 生成的默认引导令牌。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm init phase kubelet-finialize
使用以下阶段在 TLS 引导后更新与 kubelet 相关的设置。
你可以使用 all
子命令来运行所有 kubelet-finalize
阶段。
TLS 引导后更新与 kubelet 相关的设置
kubeadm init phase kubelet-finalize [flags]
示例
# 在 TLS 引导后更新与 kubelet 相关的设置
kubeadm init phase kubelet-finalize all --config
选项
-h, --help
kubelet-finalize 操作的帮助命令
继承于父命令的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
运行所有 kubelet-finalize 阶段
kubeadm init phase kubelet-finalize all [flags]
示例
# 在 TLS 引导后更新与 kubelet 相关的设置
kubeadm init phase kubelet-finalize all --config
选项
--cert-dir string 默认值: "/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
-h, --help
all 操作的帮助命令
继承于父命令的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
启用 kubelet 客户端证书轮换
kubeadm init phase kubelet-finalize experimental-cert-rotation [flags]
选项
--cert-dir string Default: "/etc/kubernetes/pki"
保存和存储证书的路径。
--config string
kubeadm 配置文件的路径。
-h, --help
experimental-cert-rotation 操作的帮助命令
继承于父命令的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
kubeadm init phase addon
可以使用 all
子命令安装所有可用的插件,或者有选择性地安装它们。
概要
此命令并非设计用来单独运行。请参阅可用子命令列表。
kubeadm init phase addon [flags]
选项
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
安装所有插件(addon)
kubeadm init phase addon all [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则将使用默认网络接口。
--apiserver-bind-port int32 默认值:6443
API 服务器绑定的端口。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
--feature-gates string
一组键值对(key=value),描述了各种特征。选项包括: IPv6DualStack=true|false (ALPHA - 默认值=false)
-h, --help
--image-repository string 默认值:"k8s.gcr.io"
选择用于拉取控制平面镜像的容器仓库
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
--pod-network-cidr string
指定 Pod 网络的 IP 地址范围。如果已设置,控制平面将自动为每个节点分配 CIDR。
--service-cidr string 默认值:"10.96.0.0/12"
为服务 VIP 使用 IP 地址的其他范围。
--service-dns-domain string 默认值:"cluster.local"
为服务使用其他域名,例如 "myorg.internal"。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
通过 API 服务器安装 CoreDNS 附加组件。请注意,即使 DNS 服务器已部署,在安装 CNI 之前 DNS 服务器不会被调度执行。
kubeadm init phase addon coredns [flags]
选项
--config string
kubeadm 配置文件的路径。
--feature-gates string
一组用来描述各种功能特性的键值(key=value)对。选项是: IPv6DualStack=true|false (ALPHA - 默认值=false)
-h, --help
coredns 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择用于拉取控制平面镜像的容器仓库
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
--service-cidr string 默认值:"10.96.0.0/12"
为服务 VIP 选择 IP 地址范围。
--service-dns-domain string 默认值:"cluster.local"
服务使用其它的域名,例如:"myorg.internal"。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
通过 API 服务器安装 kube-proxy 附加组件。
kubeadm init phase addon kube-proxy [flags]
选项
--apiserver-advertise-address string
API 服务器所公布的其正在监听的 IP 地址。如果未设置,则将使用默认网络接口。
--apiserver-bind-port int32 默认值: 6443
API 服务器绑定的端口。
--config string
kubeadm 配置文件的路径。
--control-plane-endpoint string
为控制平面指定一个稳定的 IP 地址或 DNS 名称。
-h, --help
kube-proxy 操作的帮助命令
--image-repository string 默认值:"k8s.gcr.io"
选择用于拉取控制平面镜像的容器仓库
--kubeconfig string 默认值:"/etc/kubernetes/admin.conf"
与集群通信时使用的 kubeconfig 文件。如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
--kubernetes-version string 默认值:"stable-1"
为控制平面选择特定的 Kubernetes 版本。
--pod-network-cidr string
指定 Pod 网络的 IP 地址范围。如果已设置,控制平面将自动为每个节点分配 CIDR。
继承于父命令的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
有关 v1beta2
配置中每个字段的更多详细信息,可以访问
API 。
接下来
8.1.12 - kubeadm join phase
kubeadm join phase
使你能够调用 join
过程的基本原子步骤。
因此,如果希望执行自定义操作,可以让 kubeadm 做一些工作,然后由用户来补足剩余操作。
kubeadm join phase
与
kubeadm join 工作流程
一致,后台都使用相同的代码。
kubeadm join phase
概要
使用此命令来调用 join
工作流程的某个阶段
选项
从父命令中继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
kubeadm join phase preflight
使用此命令可以在即将加入集群的节点上执行启动前检查。
概要
运行 kubeadm join 命令添加节点前检查。
kubeadm join phase preflight [api-server-endpoint] [flags]
示例
# 使用配置文件运行 kubeadm join 命令添加节点前检查。
kubeadm join phase preflight --config kubeadm-config.yml
选项
--apiserver-advertise-address string
对于将要托管新的控制平面实例的节点,指定 API 服务器将公布的其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--apiserver-bind-port int32 默认值:6443
针对将要托管新的控制平面实例的节点,设置 API 服务器要绑定的端口。
--certificate-key string
使用此密钥可以解密由 `init` 操作上传的证书 secret。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--cri-socket string
提供给 CRI 套接字建立连接的路径。如果为空,则 kubeadm 将尝试自动检测该值;仅当安装了多个 CRI 或具有非标准 CRI 套接字时,才使用此选项。
--discovery-file string
对于基于文件的发现,给出用于加载集群信息的文件或者 URL。
--discovery-token string
对于基于令牌的发现,该令牌用于验证从 API 服务器获取的集群信息。
--discovery-token-ca-cert-hash stringSlice
对于基于令牌的发现,验证根 CA 公钥是否匹配此哈希值(格式:"<type>:<value>")。
--discovery-token-unsafe-skip-ca-verification
对于基于令牌的发现,允许在未关联 --discovery-token-ca-cert-hash 参数的情况下添加节点。
-h, --help
preflight 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查列表;例如:'IsPrivilegedUser,Swap'。取值为 'all' 时将忽略检查中的所有错误。
--node-name string
指定节点名称。
--tls-bootstrap-token string
指定在加入节点时用于临时通过 Kubernetes 控制平面进行身份验证的令牌。
--token string
如果未提供这些值,则将它们用于 discovery-token 令牌和 tls-bootstrap 令牌。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
kubeadm join phase control-plane-prepare
使用此阶段,你可以准备一个作为控制平面的节点。
概要
准备为控制平面服务的机器
kubeadm join phase control-plane-prepare [flags]
示例
# 准备为控制平面服务的机器
kubeadm join phase control-plane-prepare all
选项
-h, --help
control-plane-prepare 操作的帮助命令
从父命令中继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
概要
准备为控制平面服务的机器
kubeadm join phase control-plane-prepare all [api-server-endpoint] [flags]
选项
--apiserver-advertise-address string
如果该节点托管一个新的控制平面实例,则 API 服务器将公布其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--apiserver-bind-port int32 默认值:6443
如果该节点托管一个新的控制平面实例,则为 API 服务器要绑定的端口。
--certificate-key string
使用此密钥解密由 init 上传的证书 secrets。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--discovery-file string
对于基于文件的发现,给出用于加载集群信息的文件或者 URL。
--discovery-token string
对于基于令牌的发现,该令牌用于验证从 API 服务器获取的集群信息。
--discovery-token-ca-cert-hash stringSlice
对于基于令牌的发现,请验证根 CA 公钥是否匹配此哈希值(格式:"<type>:<value>")。
--discovery-token-unsafe-skip-ca-verification
对于基于令牌的发现,允许在未关联 --discovery-token-ca-cert-hash 参数的情况下添加节点。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
-h, --help
all 操作的帮助命令
--node-name string
指定节点名称。
--tls-bootstrap-token string
指定在加入节点时用于临时通过 Kubernetes 控制平面进行身份验证的令牌。
--token string
如果未提供这些值,则将它们用于 discovery-token 令牌和 tls-bootstrap 令牌。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
概要
[实验]从 kubeadm-certs Secret 下载控制平面节点之间共享的证书
kubeadm join phase control-plane-prepare download-certs [api-server-endpoint] [flags]
选项
--certificate-key string
使用此密钥可以解密由 init 上传的证书 secret。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--discovery-file string
对于基于文件的发现,给出用于加载集群信息的文件或者 URL。
--discovery-token string
对于基于令牌的发现,该令牌用于验证从 API 服务器获取的集群信息。
--discovery-token-ca-cert-hash stringSlice
对于基于令牌的发现,请验证根 CA 公钥是否匹配此哈希值(格式:"<type>:<value>")。
--discovery-token-unsafe-skip-ca-verification
对于基于令牌的发现,允许在未关联 --discovery-token-ca-cert-hash 参数的情况下添加节点。
-h, --help
kubeconfig 操作的帮助命令
--tls-bootstrap-token string
指定在加入节点时用于临时通过 Kubernetes 控制平面进行身份验证的令牌。
--token string
如果未提供这些值,则将它们用于 discovery-token 令牌和 tls-bootstrap 令牌。
从父命令中继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
概要
为新的控制平面组件生成证书
kubeadm join phase control-plane-prepare certs [api-server-endpoint] [flags]
选项
--apiserver-advertise-address string
如果该节点托管一个新的控制平面实例,则 API 服务器将公布其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--discovery-file string
对于基于文件的发现,给出用于加载集群信息的文件或者 URL。
--discovery-token string
对于基于令牌的发现,该令牌用于验证从 API 服务器获取的集群信息。
--discovery-token-ca-cert-hash stringSlice
对于基于令牌的发现,请验证根 CA 公钥是否匹配此哈希值(格式:"<type>:<value>")。
--discovery-token-unsafe-skip-ca-verification
对于基于令牌的发现,允许在未关联 --discovery-token-ca-cert-hash 参数的情况下添加节点。
-h, --help
certs 操作的帮助命令
--node-name string
指定节点名称。
--tls-bootstrap-token string
指定在加入节点时用于临时通过 Kubernetes 控制平面进行身份验证的令牌。
--token string
如果未提供这些值,则将它们用于 discovery-token 令牌和 tls-bootstrap 令牌。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
概要
为新的控制平面组件生成 kubeconfig
kubeadm join phase control-plane-prepare kubeconfig [api-server-endpoint] [flags]
选项
--certificate-key string
使用此密钥可以解密由 init 上传的证书 secret。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--discovery-file string
对于基于文件的发现,给出用于加载集群信息的文件或者 URL。
--discovery-token string
对于基于令牌的发现,该令牌用于验证从 API 服务器获取的集群信息。
--discovery-token-ca-cert-hash stringSlice
对于基于令牌的发现,请验证根 CA 公钥是否匹配此哈希值(格式:"<type>:<value>")。
--discovery-token-unsafe-skip-ca-verification
对于基于令牌的发现,允许在未关联 --discovery-token-ca-cert-hash 参数的情况下添加节点。
-h, --help
kubeconfig 操作的帮助命令
--tls-bootstrap-token string
指定在加入节点时用于临时通过 Kubernetes 控制平面进行身份验证的令牌。
--token string
如果未提供这些值,则将它们用于 discovery-token 令牌和 tls-bootstrap 令牌。
从父命令中继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
概要
为新的控制平面组件生成清单(manifest)
kubeadm join phase control-plane-prepare control-plane [flags]
选项
--apiserver-advertise-address string
对于将要托管新的控制平面实例的节点,指定 API 服务器将公布的其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--apiserver-bind-port int32 默认值:6443
针对将要托管新的控制平面实例的节点,设置 API 服务器要绑定的端口。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
-h, --help
control-plane 操作的帮助命令
从父命令中继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
kubeadm join phase kubelet-start
使用此阶段,你可以配置 kubelet 设置、证书和(重新)启动 kubelet。
概要
生成一个包含 KubeletConfiguration 的文件和一个包含特定于节点的 kubelet 配置的环境文件,然后(重新)启动 kubelet。
kubeadm join phase kubelet-start [api-server-endpoint] [flags]
选项
--config string
kubeadm 配置文件的路径。
--cri-socket string
提供给 CRI 套接字建立连接的路径。如果为空,则 kubeadm 将尝试自动检测该值;仅当安装了多个 CRI 或具有非标准 CRI 套接字时,才使用此选项。
--discovery-file string
For file-based discovery, a file or URL from which to load cluster information.
对于基于文件的发现,给出用于加载集群信息的文件或者 URL。
--discovery-token string
对于基于令牌的发现,该令牌用于验证从 API 服务器获取的集群信息。
--discovery-token-ca-cert-hash stringSlice
对于基于令牌的发现,验证根 CA 公钥是否匹配此哈希值(格式:"<type>:<value>")。
--discovery-token-unsafe-skip-ca-verification
对于基于令牌的发现,允许在未关联 --discovery-token-ca-cert-hash 参数的情况下添加节点。
-h, --help
kubelet-start 操作的帮助命令
--node-name string
指定节点名称。
--tls-bootstrap-token string
指定在加入节点时用于临时通过 Kubernetes 控制平面进行身份验证的令牌。
--token string
如果未提供这些值,则将它们用于 discovery-token 令牌和 tls-bootstrap 令牌。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
kubeadm join phase control-plane-join
使用此阶段,你可以将节点作为控制平面实例加入。
概要
添加作为控制平面实例的机器
kubeadm join phase control-plane-join [flags]
示例
# 将机器作为控制平面实例加入
kubeadm join phase control-plane-join all
选项
-h, --help
control-plane-join 操作的帮助命令
从父命令中继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
添加作为控制平面实例的机器
kubeadm join phase control-plane-join all [flags]
选项
--apiserver-advertise-address string
如果该节点托管一个新的控制平面实例,则 API 服务器将公布其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--config string
kubeadm 配置文件的路径。
--experimental-control-plane
在此节点上创建一个新的控制平面实例
-h, --help
all 操作的帮助命令
--node-name string
指定节点名称。
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
添加新的本地 etcd 成员
kubeadm join phase control-plane-join etcd [flags]
选项
--apiserver-advertise-address string
如果该节点托管一个新的控制平面实例,则 API 服务器将公布其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是"strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
-h, --help
etcd 操作的帮助命令
--node-name string
指定节点的名称
从父命令中继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
将新的控制平面节点注册到 kubeadm-config ConfigMap 维护的 ClusterStatus 中
kubeadm join phase control-plane-join update-status [flags]
选项
--apiserver-advertise-address string
如果该节点托管一个新的控制平面实例,则 API 服务器将公布其正在侦听的 IP 地址。如果未设置,则使用默认网络接口。
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
-h, --help
update-status 操作的帮助命令
--node-name string
指定节点名称。
从父命令中继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
概要
将 Node 节点标记为控制平面节点
kubeadm join phase control-plane-join mark-control-plane [flags]
选项
--config string
kubeadm 配置文件的路径。
--control-plane
在此节点上创建一个新的控制平面实例
-h, --help
mark-control-plane 操作的帮助命令
--node-name string
指定节点的名称
从父命令中继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
接下来
8.1.13 - kubeadm kubeconfig
kubeadm kubeconfig
提供用来管理 kubeconfig 文件的工具。
如果希望查看如何使用 kubeadm kubeconfig user
的示例,请参阅
为其他用户生成 kubeconfig 文件 .
kubeadm kubeconfig
Kubeconfig 文件工具。
概要
kubeconfig 文件工具。
选项
-h, --help
kubeconfig 操作的帮助命令
从父命令继承的选项
--rootfs string
[实验] 到 '真实' 主机根文件系统的路径。
kubeadm kubeconfig user
此命令可用来为其他用户生成一个 kubeconfig 文件。
为其他用户输出一个 kubeconfig 文件。
概要
为其他用户输出一个 kubeconfig 文件。
kubeadm alpha kubeconfig user [flags]
示例
# 使用名为 bar 的 kubeadm 配置文件为名为 foo 的另一用户输出 kubeconfig 文件
kubeadm kubeconfig user --client-name=foo --config=bar
选项
--client-name string
用户名。如果生成客户端证书,则用作其 CN。
--config string
指向 kubeadm 配置文件的路径
-h, --help
user 操作的帮助命令
--org strings
客户端证书的组织。如果创建客户端证书,此值将用作其 O 字段值。
--token string
应该用此令牌做为 kubeconfig 的身份验证机制,而不是客户端证书
--validity-period duration Default: 8760h0m0s
客户证书的合法期限。所设置值为相对当前时间的偏移。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机的根目录。
8.1.14 - kubeadm reset phase
kubeadm reset phase
使你能够调用 reset
过程的基本原子步骤。
因此,如果希望执行自定义操作,可以让 kubeadm 做一些工作,然后由用户来补足剩余操作。
kubeadm reset phase
与
kubeadm reset 工作流程
一致,后台都使用相同的代码。
kubeadm reset phase
概要
使用此命令来调用 reset
工作流程的某个阶段
选项
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
kubeadm reset phase preflight
使用此阶段,你可以在要重置的节点上执行启动前检查阶段。
概要
kubeadm reset(重置)前运行启动前检查。
kubeadm reset phase preflight [flags]
选项
-f, --force
在不提示确认的情况下重置节点。
-h, --help
preflight 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查列表;例如:'IsPrivilegedUser,Swap'。取值为 'all' 时将忽略检查中的所有错误。
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
kubeadm reset phase update-cluster-status
使用此阶段,你可以从 ClusterStatus 对象中删除此控制平面节点。
概要
如果该节点是控制平面节点,从 ClusterStatus 对象中删除该节点。
kubeadm reset phase update-cluster-status [flags]
选项
-h, --help
update-cluster-status 操作的帮助命令
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
kubeadm reset phase remove-etcd-member
使用此阶段,你可以从 etcd 集群中删除此控制平面节点的 etcd 成员。
概要
上传关于当前状态的配置,以便 'kubeadm upgrade' 以后可以知道如何配置升级后的集群。
kubeadm config upload [flags]
选项
-h, --help
upload 操作的帮助信息
从父命令继承的选项
--kubeconfig string 默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
kubeadm reset phase cleanup-node
使用此阶段,你可以在此节点上执行清理工作。
概要
执行 cleanup node(清理节点)操作。
kubeadm reset phase cleanup-node [flags]
选项
--cert-dir string 默认值:"/etc/kubernetes/pki"
存储证书的目录路径。如果已指定,则需要清空此目录。
--cri-socket string
要连接的 CRI 套接字的路径。如果为空,则 kubeadm 将尝试自动检测此值;仅当安装了多个CRI 或具有非标准 CRI 插槽时,才使用此选项。
-h, --help
cleanup-node 操作的帮助命令
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
接下来
8.1.15 - kubeadm upgrade phase
在 Kubernetes v1.15.0 版本中,kubeadm 引入了对 kubeadm upgrade node
阶段的初步支持。其他 kubeadm upgrade
子命令如 apply
等阶段将在未来发行版中添加。
kubeadm upgrade node phase
使用此阶段,可以选择执行辅助控制平面或工作节点升级的单独步骤。请注意,kubeadm upgrade apply
命令仍然必须在主控制平面节点上调用。
概要
使用此命令调用 node 工作流的某个阶段
选项
从父命令继承的选项
--rootfs string
[实验] 指向 '真实' 宿主机根文件系统的路径。
执行 kubeadm 升级节点的预检。
kubeadm upgrade node phase preflight [flags]
选项
-h, --help
preflight 操作的帮助命令
--ignore-preflight-errors stringSlice
错误将显示为警告的检查清单。示例:'IsPrivilegedUser,Swap'。值为'all'表示忽略所有检查的错误。
继承于父命令的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
概要
升级部署在此节点上的控制平面实例,如果有的话
kubeadm upgrade node phase control-plane [flags]
选项
--certificate-renewal
更新在升级期间变更的组件使用的证书。
--dry-run
不改变任何状态,只输出将要执行的动作。
--etcd-upgrade 默认值: true
执行 etcd 的升级。
--experimental-patches string
包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。
例如,"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。
"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一,并且它们与 kubectl 支持的补丁格式匹配。
默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。
"suffix" 是一个可选字符串,可用于确定首先按字母顺序应用哪些补丁。
-h, --help
control-plane 的帮助信息
--kubeconfig string 默认值: "/etc/kubernetes/admin.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
从父命令继承的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
从群集中 "kubelet-config-1.X" 的 ConfigMap 下载 kubelet 配置,其中 X 是kubelet 的次要版本。
kubeadm 使用 --kubelet-version 参数来确定所需的 kubelet 版本。
kubeadm upgrade node phase kubelet-config [flags]
选项
--dry-run
不改变任何状态,只输出将要执行的操作
-h, --help
配置操作的帮助信息
--kubeconfig string 默认值: "/etc/kubernetes/kubelet.conf"
用于和集群通信的 KubeConfig 文件。如果它没有被设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
--kubelet-version string
升级后的 kubelet 的*期望*版本。
从父命令继承的选项
--rootfs string
[实验] 到'真实'主机根文件系统的路径。
接下来
8.1.16 - 实现细节
FEATURE STATE: Kubernetes v1.10 [stable]
kubeadm init
和 kubeadm join
结合在一起提供了良好的用户体验,因为从头开始创建实践最佳而配置最基本的 Kubernetes 集群。
但是,kubeadm 如何 做到这一点可能并不明显。
本文档提供了更多幕后的详细信息,旨在分享有关 Kubernetes 集群最佳实践的知识。
核心设计原则
kubeadm init
和 kubeadm join
设置的集群该是:
安全的 :它应采用最新的最佳实践,例如:
实施 RBAC 访问控制
使用节点鉴权机制(Node Authorizer)
在控制平面组件之间使用安全通信
在 API 服务器和 kubelet 之间使用安全通信
锁定 kubelet API
锁定对系统组件(例如 kube-proxy 和 CoreDNS)的 API 的访问
锁定启动引导令牌(Bootstrap Token)可以访问的内容
用户友好 :用户只需要运行几个命令即可:
kubeadm init
export KUBECONFIG=/etc/kubernetes/admin.conf
kubectl apply -f <所选网络.yaml>
kubeadm join --token <令牌> <端点>:<端口>
可扩展的 :
不 应偏向任何特定的网络提供商。不涉及配置集群网络
应该可以使用配置文件来自定义各种参数
常量以及众所周知的值和路径
为了降低复杂性并简化基于 kubeadm 的高级工具的开发,对于众所周知的路径和文件名,
kubeadm 使用了一组有限的常量值。
Kubernetes 目录 /etc/kubernetes
在应用程序中是一个常量,因为在大多数情况下
它显然是给定的路径,并且是最直观的位置;其他路径常量和文件名有:
/etc/kubernetes/manifests
作为 kubelet 查找静态 Pod 清单的路径。静态 Pod 清单的名称为:
etcd.yaml
kube-apiserver.yaml
kube-controller-manager.yaml
kube-scheduler.yaml
/etc/kubernetes/
作为带有控制平面组件身份标识的 kubeconfig 文件的路径。kubeconfig 文件的名称为:
kubelet.conf
(在 TLS 引导时名称为 bootstrap-kubelet.conf
)
controller-manager.conf
scheduler.conf
admin.conf
用于集群管理员和 kubeadm 本身
证书和密钥文件的名称:
ca.crt
, ca.key
用于 Kubernetes 证书颁发机构
apiserver.crt
, apiserver.key
用于 API 服务器证书
apiserver-kubelet-client.crt
, apiserver-kubelet-client.key
用于 API 服务器安全地连接到 kubelet 的客户端证书
sa.pub
, sa.key
用于控制器管理器签署 ServiceAccount 时使用的密钥
front-proxy-ca.crt
, front-proxy-ca.key
用于前端代理证书颁发机构
front-proxy-client.crt
, front-proxy-client.key
用于前端代理客户端
kubeadm init 工作流程内部设计
kubeadm init
内部工作流程
包含一系列要执行的原子性工作任务,如 kubeadm init
中所述。
kubeadm init phase
命令允许用户分别调用每个任务,并最终提供可重用且可组合的 API 或工具箱,
其他 Kubernetes 引导工具、任何 IT 自动化工具和高级用户都可以使用它来
创建自定义集群。
预检
Kubeadm 在启动 init 之前执行一组预检,目的是验证先决条件并避免常见的集群启动问题。
用户可以使用 --ignore-preflight-errors
选项跳过特定的预检查或全部检查。
[警告] 如果要使用的 Kubernetes 版本(由 --kubernetes-version
标志指定)比 kubeadm CLI
版本至少高一个小版本。
Kubernetes 系统要求:
如果在 linux上运行:
[错误] 如果内核早于最低要求的版本
[错误] 如果未设置所需的 cgroups 子系统
如果使用 docker:
[警告/错误] 如果 Docker 服务不存在、被禁用或未激活。
[错误] 如果 Docker 端点不存在或不起作用
[警告] 如果 docker 版本不在经过验证的 docker 版本列表中
如果使用其他 cri 引擎:
[错误] 如果用户不是 root 用户
[错误] 如果机器主机名不是有效的 DNS 子域
[警告] 如果通过网络查找无法访问主机名
[错误] 如果 kubelet 版本低于 kubeadm 支持的最低 kubelet 版本(当前小版本 -1)
[错误] 如果 kubelet 版本比所需的控制平面板版本至少高一个小(不支持的版本偏斜)
[警告] 如果 kubelet 服务不存在或已被禁用
[警告] 如果 firewalld 处于活动状态
[错误] 如果 API 服务器绑定的端口或 10250/10251/10252 端口已被占用
[错误] 如果 /etc/kubernetes/manifest
文件夹已经存在并且不为空
[错误] 如果 /proc/sys/net/bridge/bridge-nf-call-iptables
文件不存在或不包含 1
[错误] 如果建议地址是 ipv6,并且 /proc/sys/net/bridge/bridge-nf-call-ip6tables
不存在或不包含 1
[错误] 如果启用了交换分区
[错误] 如果命令路径中没有 conntrack
、ip
、iptables
、mount
、nsenter
命令
[警告] 如果命令路径中没有 ebtables
、ethtool
、socat
、tc
、touch
、crictl
命令
[警告] 如果 API 服务器、控制器管理器、调度程序的其他参数标志包含一些无效选项
[警告] 如果与 https://API.AdvertiseAddress:API.BindPort 的连接通过代理
[警告] 如果服务子网的连接通过代理(仅检查第一个地址)
[警告] 如果 Pod 子网的连接通过代理(仅检查第一个地址)
如果提供了外部 etcd:
[错误] 如果 etcd 版本低于最低要求版本
[错误] 如果指定了 etcd 证书或密钥,但无法找到
如果未提供外部 etcd(因此将安装本地 etcd):
[错误] 如果端口 2379 已被占用
[错误] 如果 Etcd.DataDir 文件夹已经存在并且不为空
如果授权模式为 ABAC:
[错误] 如果 abac_policy.json 不存在
如果授权方式为 Webhook
[错误] 如果 webhook_authz.conf 不存在
请注意:
可以使用 kubeadm init phase preflight
命令单独触发预检。
生成必要的证书
Kubeadm 生成用于不同目的的证书和私钥对:
Kubernetes 集群的自签名证书颁发机构会保存到 ca.crt
文件和 ca.key
私钥文件中
用于 API 服务器的服务证书,使用 ca.crt
作为 CA 生成,并将证书保存到 apiserver.crt
文件中,私钥保存到 apiserver.key
文件中
该证书应包含以下备用名称:
Kubernetes 服务的内部 clusterIP(服务 CIDR 的第一个地址。
例如:如果服务的子网是 10.96.0.0/12
,则为 10.96.0.1
)
Kubernetes DNS 名称,例如:如果 --service-dns-domain
标志值是 cluster.local
,
则为 kubernetes.default.svc.cluster.local
;
加上默认的 DNS 名称 kubernetes.default.svc
、kubernetes.default
和 kubernetes
,
节点名称
--apiserver-advertise-address
用户指定的其他备用名称
用于 API 服务器安全连接到 kubelet 的客户端证书,使用 ca.crt
作为 CA 生成,
并保存到 apiserver-kubelet-client.crt
,私钥保存到 apiserver-kubelet-client.key
文件中。该证书应该在 system:masters
组织中。
用于签名 ServiceAccount 令牌的私钥保存到 sa.key
文件中,公钥保存到 sa.pub
文件中
用于前端代理的证书颁发机构保存到 front-proxy-ca.crt
文件中,私钥保存到
front-proxy-ca.key
文件中
前端代理客户端的客户端证书,使用 front-proxy-ca.crt
作为 CA 生成,并保存到
front-proxy-client.crt
文件中,私钥保存到 front-proxy-client.key
文件中
证书默认情况下存储在 /etc/kubernetes/pki
中,但是该目录可以使用 --cert-dir
标志进行配置。
请注意:
如果证书和私钥对都存在,并且其内容经过评估符合上述规范,将使用现有文件,
并且跳过给定证书的生成阶段。
这意味着用户可以将现有的 CA 复制到 /etc/kubernetes/pki/ca.{crt,key}
,
kubeadm 将使用这些文件对其余证书进行签名。
请参阅使用自定义证书 。
仅对 CA 来说,如果所有其他证书和 kubeconfig 文件都已就位,则可以只提供 ca.crt
文件,
而不提供 ca.key
文件。
kubeadm 能够识别出这种情况并启用 ExternalCA,这也意味着了控制器管理器中的
csrsigner
控制器将不会启动
如果 kubeadm 在
外部 CA 模式
下运行,所有证书必须由用户提供,因为 kubeadm 无法自行生成它们。
如果在 --dry-run
模式下执行 kubeadm,证书文件将写入一个临时文件夹中
可以使用 kubeadm init phase certs all
命令单独生成证书。
为控制平面组件生成 kubeconfig 文件
Kubeadm 生成具有用于控制平面组件身份标识的 kubeconfig 文件:
供 kubelet 在 TLS 引导期间使用的 kubeconfig 文件 —— /etc/kubernetes/bootstrap-kubelet.conf
。
在此文件中,有一个引导令牌或内嵌的客户端证书,向集群表明此节点身份。
此客户端证书应:
根据节点鉴权 模块的要求,属于 system:nodes
组织
具有通用名称(CN):system:node:<小写主机名>
控制器管理器的 kubeconfig 文件 —— /etc/kubernetes/controller-manager.conf
;
在此文件中嵌入了一个具有控制器管理器身份标识的客户端证书。
此客户端证书应具有 CN:system:kube-controller-manager
,
该 CN 由 RBAC 核心组件角色
默认定义的。
调度器的 kubeconfig 文件 —— /etc/kubernetes/scheduler.conf
;
此文件中嵌入了具有调度器身份标识的客户端证书。此客户端证书应具有 CN:system:kube-scheduler
,
该 CN 由 RBAC 核心组件角色
默认定义的。
另外,用于 kubeadm 本身和 admin 的 kubeconfig 文件也被生成并保存到
/etc/kubernetes/admin.conf
文件中。
此处的 admin 定义为正在管理集群并希望完全控制集群(root )的实际人员。
内嵌的 admin 客户端证书应是 system:masters
组织的成员,
这一组织名由默认的 RBAC 面向用户的角色绑定
定义。它还应包括一个 CN。kubeadm 使用 kubernetes-admin
CN。
请注意:
ca.crt
证书内嵌在所有 kubeconfig 文件中。
如果给定的 kubeconfig 文件存在且其内容经过评估符合上述规范,则 kubeadm 将使用现有文件,
并跳过给定 kubeconfig 的生成阶段
如果 kubeadm 以 ExternalCA 模式
运行,则所有必需的 kubeconfig 也必须由用户提供,因为 kubeadm 不能自己生成
如果在 --dry-run
模式下执行 kubeadm,则 kubeconfig 文件将写入一个临时文件夹中
可以使用
kubeadm init phase kubeconfig all
命令分别生成 kubeconfig 文件。
为控制平面组件生成静态 Pod 清单
Kubeadm 将用于控制平面组件的静态 Pod 清单文件写入 /etc/kubernetes/manifests
目录。
Kubelet 启动后会监视这个目录以便创建 Pod。
静态 Pod 清单有一些共同的属性:
所有静态 Pod 都部署在 kube-system
名字空间
所有静态 Pod 都打上 tier:ontrol-plane
和 component:{组件名称}
标签
所有静态 Pod 均使用 system-node-critical
优先级
所有静态 Pod 都设置了 hostNetwork:true
,使得控制平面在配置网络之前启动;结果导致:
控制器管理器和调度器用来调用 API 服务器的地址为 127.0.0.1。
如果使用本地 etcd 服务器,则 etcd-servers
地址将设置为 127.0.0.1:2379
同时为控制器管理器和调度器启用了领导者选举
控制器管理器和调度器将引用 kubeconfig 文件及其各自的唯一标识
如将自定义参数传递给控制平面组件
中所述,所有静态 Pod 都会获得用户指定的额外标志
所有静态 Pod 都会获得用户指定的额外卷(主机路径)
请注意:
所有镜像默认从 k8s.gcr.io 拉取。
关于自定义镜像仓库,请参阅
使用自定义镜像 。
如果在 --dry-run
模式下执行 kubeadm,则静态 Pod 文件写入一个临时文件夹中。
可以使用 kubeadm init phase control-plane all
命令分别生成主控组件的静态 Pod 清单。
API 服务器
API 服务器的静态 Pod 清单会受到用户提供的以下参数的影响:
要绑定的 apiserver-advertise-address
和 apiserver-bind-port
;
如果未提供,则这些值默认为机器上默认网络接口的 IP 地址和 6443 端口。
service-cluster-ip-range
给 service 使用
如果指定了外部 etcd 服务器,则应指定 etcd-servers
地址和相关的 TLS 设置
(etcd-cafile
,etcd-certfile
,etcd-keyfile
);
如果未提供外部 etcd 服务器,则将使用本地 etcd(通过主机网络)
如果指定了云提供商,则配置相应的 --cloud-provider
,如果该路径存在,则配置 --cloud-config
(这是实验性的,是 Alpha 版本,将在以后的版本中删除)
无条件设置的其他 API 服务器标志有:
--insecure-port=0
禁止到 API 服务器不安全的连接
--enable-bootstrap-token-auth=true
启用 BootstrapTokenAuthenticator
身份验证模块。
更多细节请参见 TLS 引导 。
--allow-privileged
设为 true
(诸如 kube-proxy 这些组件有此要求)
--requestheader-client-ca-file
设为 front-proxy-ca.crt
--enable-admission-plugins
设为:
--kubelet-preferred-address-types
设为 InternalIP,ExternalIP,Hostname;
这使得在节点的主机名无法解析的环境中,kubectl log
和 API 服务器与 kubelet
的其他通信可以工作
使用在前面步骤中生成的证书的标志:
--client-ca-file
设为 ca.crt
--tls-cert-file
设为 apiserver.crt
--tls-private-key-file
设为 apiserver.key
--kubelet-client-certificate
设为 apiserver-kubelet-client.crt
--kubelet-client-key
设为 apiserver-kubelet-client.key
--service-account-key-file
设为 sa.pub
--requestheader-client-ca-file
设为 front-proxy-ca.crt
--proxy-client-cert-file
设为 front-proxy-client.crt
--proxy-client-key-file
设为 front-proxy-client.key
其他用于保护前端代理(
API 聚合层 )
通信的标志:
--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-allowed-names=front-proxy-client
控制器管理器
控制器管理器的静态 Pod 清单受用户提供的以下参数的影响:
如果调用 kubeadm 时指定了 --pod-network-cidr
参数,则可以通过以下方式启用
某些 CNI 网络插件所需的子网管理器功能:
设置 --allocate-node-cidrs=true
根据给定 CIDR 设置 --cluster-cidr
和 --node-cidr-mask-size
标志
如果指定了云提供商,则指定相应的 --cloud-provider
,如果存在这样的配置文件,
则指定 --cloud-config
路径(此为试验性功能,是 Alpha 版本,将在以后的版本中删除)。
其他无条件设置的标志包括:
--controllers
为 TLS 引导程序启用所有默认控制器以及 BootstrapSigner
和
TokenCleaner
控制器。详细信息请参阅
TLS 引导
--use-service-account-credentials
设为 true
使用先前步骤中生成的证书的标志:
---root-ca-file
设为 ca.crt
如果禁用了 External CA 模式,则 --cluster-signing-cert-file
设为 ca.crt
,否则设为 ""
如果禁用了 External CA 模式,则 --cluster-signing-key-file
设为 ca.key
,否则设为 ""
--service-account-private-key-file
设为 sa.key
调度器
调度器的静态 Pod 清单不受用户提供的参数的影响。
为本地 etcd 生成静态 Pod 清单
如果用户指定了外部 etcd,则将跳过此步骤,否则 kubeadm 会生成静态 Pod 清单文件,
以创建在 Pod 中运行的具有以下属性的本地 etcd 实例:
在 localhost:2379
上监听并使用 HostNetwork=true
将 hostPath
从 dataDir
挂载到主机的文件系统
用户指定的任何其他标志
请注意:
etcd 镜像默认从 k8s.gcr.io
拉取。有关自定义镜像仓库,请参阅
使用自定义镜像 。
如果 kubeadm 以 --dry-run
模式执行,etcd 静态 Pod 清单将写入一个临时文件夹。
可以使用
'kubeadm init phase etcd local'
命令单独为本地 etcd 生成静态 Pod 清单
等待控制平面启动
kubeadm 等待(最多 4m0s),直到 localhost:6443/healthz
(kube-apiserver 存活)返回 ok
。
但是为了检测死锁条件,如果 localhost:10255/healthz
(kubelet 存活)或
localhost:10255/healthz/syncloop
(kubelet 就绪)未能在 40s 和 60s 内未返回 ok
,
则 kubeadm 会快速失败。
kubeadm 依靠 kubelet 拉取控制平面镜像并将其作为静态 Pod 正确运行。
控制平面启动后,kubeadm 将完成以下段落中描述的任务。
将 kubeadm ClusterConfiguration 保存在 ConfigMap 中以供以后参考
kubeadm 将传递给 kubeadm init
的配置保存在 kube-system
名字空间下名为
kubeadm-config
的 ConfigMap 中。
这将确保将来执行的 kubeadm 操作(例如 kubeadm upgrade
)将能够确定实际/当前集群状态,
并根据该数据做出新的决策。
请注意:
在保存 ClusterConfiguration 之前,从配置中删除令牌等敏感信息。
可以使用
kubeadm init phase upload-config
命令单独上传主控节点配置。
将节点标记为控制平面
一旦控制平面可用,kubeadm 将执行以下操作:
给节点打上 node-role.kubernetes.io/master=""
标签,标记其为控制平面
给节点打上 node-role.kubernetes.io/master:NoSchedule
污点
请注意:
可以使用 kubeadm init phase mark-control-plane
命令单独触发控制平面标记
Kubeadm 使用引导令牌认证
将新节点连接到现有集群;
更多的详细信息,请参见
设计提案 。
kubeadm init
确保为该过程正确配置了所有内容,这包括以下步骤以及设置 API 服务器
和控制器标志,如前几段所述。
请注意:
可以使用
kubeadm init phase bootstrap-token
命令配置节点的 TLS 引导,执行以下段落中描述的所有配置步骤;
或者每个步骤都单独触发。
创建引导令牌
kubeadm init
创建第一个引导令牌,该令牌是自动生成的或由用户提供的 --token
标志的值;如引导令牌规范中记录的那样,
令牌应保存在 kube-system
名字空间下名为 bootstrap-token-<令牌-id>
的 Secret 中。
请注意:
由 kubeadm init
创建的默认令牌将用于在 TLS 引导过程中验证临时用户;
这些用户会成为 system:bootstrappers:kubeadm:default-node-token
组的成员。
令牌的有效期有限,默认为 24 小时(间隔可以通过 -token-ttl
标志进行更改)
可以使用 kubeadm token
命令创建其他令牌,这些令牌还提供其他有用的令牌管理功能
允许加入的节点调用 CSR API
Kubeadm 确保 system:bootstrappers:kubeadm:default-node-token
组中的用户
能够访问证书签名 API。
这是通过在上述组与默认 RBAC 角色 system:node-bootstrapper
之间创建名为
kubeadm:kubelet-bootstrap
的 ClusterRoleBinding 来实现的。
为新的引导令牌设置自动批准
Kubeadm 确保 csrapprover 控制器自动批准引导令牌的 CSR 请求。
这是通过在 system:bootstrappers:kubeadm:default-node-token
用户组和
system:certificates.k8s.io:certificatesigningrequests:nodeclient
默认角色之间
创建名为 kubeadm:node-autoapprove-bootstrap
的 ClusterRoleBinding 来实现的。
还应创建 system:certificates.k8s.io:certificatesigningrequests:nodeclient
角色,
授予对 /apis/certificates.k8s.io/certificatesigningrequests/nodeclient
执行 POST 的权限。
通过自动批准设置节点证书轮换
Kubeadm 确保节点启用了证书轮换,csrapprover 控制器将自动批准节点的
新证书的 CSR 请求。
这是通过在 system:nodes
组和
system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
默认角色之间创建名为 kubeadm:node-autoapprove-certificate-rotation
的
ClusterRoleBinding 来实现的。
创建公共 cluster-info ConfigMap
本步骤在 kube-public
名字空间中创建名为 cluster-info
的 ConfigMap。
另外,它创建一个 Role 和一个 RoleBinding,为未经身份验证的用户授予对 ConfigMap
的访问权限(即 RBAC 组 system:unauthenticated
中的用户)。
请注意:
对 cluster-info
ConfigMap 的访问 不受 速率限制。
如果你把 API 服务器暴露到外网,这可能是一个问题,也可能不是;
这里最坏的情况是 DoS 攻击,攻击者使用 kube-apiserver 能够处理的所有动态请求
来为 cluster-info
ConfigMap 提供服务。
安装插件
Kubeadm 通过 API 服务器安装内部 DNS 服务器和 kube-proxy 插件。
请注意:
此步骤可以调用
'kubeadm init phase addon all'
命令单独执行。
代理
在 kube-system
名字空间中创建一个用于 kube-proxy
的 ServiceAccount;
然后以 DaemonSet 的方式部署 kube-proxy:
主控节点凭据(ca.crt
和 token
)来自 ServiceAccount
API 服务器节点的位置(URL)来自 ConfigMap
kube-proxy
的 ServiceAccount 绑定了 system:node-proxier
ClusterRole
中的特权
DNS
CoreDNS 服务的名称为 kube-dns
。这样做是为了防止当用户将集群 DNS 从 kube-dns
切换到 CoreDNS 时出现服务中断。--config
方法在
这里
有描述。
在 kube-system
名字空间中创建 CoreDNS 的 ServiceAccount
coredns
的 ServiceAccount 绑定了 system:coredns
ClusterRole 中的特权
在 Kubernetes 1.21 版本中,kubeadm 对 kube-dns
的支持被移除。
你可以在 kubeadm 使用 CoreDNS,即使相关的 Service 名字仍然是 kube-dns
。
kubeadm join 步骤内部设计
与 kubeadm init
类似,kubeadm join
内部工作流由一系列待执行的原子工作任务组成。
这分为发现(让该节点信任 Kubernetes 的主控节点)和 TLS 引导
(让 Kubernetes 的主控节点信任该节点)。
请参阅使用引导令牌进行身份验证
或相应的设计提案 。
预检
kubeadm
在开始执行之前执行一组预检,目的是验证先决条件,避免常见的集群启动问题。
请注意:
kubeadm join
预检基本上是 kubeadm init
预检的一个子集
从 1.9 开始,kubeadm 为 CRI 通用的功能提供了更好的支持;在这种情况下,
Docker 特定的控制参数将跳过或替换为 crictl 中与之相似的控制参数。
从 1.9 开始,kubeadm 支持加入在 Windows 上运行的节点;在这种情况下,
将跳过 Linux 特定的控制参数。
在任何情况下,用户都可以通过 --ignore-preflight-errors
选项跳过
特定的预检(或者进而跳过所有预检)。
发现 cluster-info
主要有两种发现方案。第一种是使用一个共享令牌以及 API 服务器的 IP 地址。
第二种是提供一个文件(它是标准 kubeconfig 文件的子集)。
共享令牌发现
如果带 --discovery-token
参数调用 kubeadm join
,则使用了令牌发现功能;
在这种情况下,节点基本上从 kube-public
名字空间中的 cluster-info
ConfigMap
中检索集群 CA 证书。
为了防止“中间人”攻击,采取了以下步骤:
首先,通过不安全连接检索 CA 证书(这是可能的,因为 kubeadm init
授予
system:unauthenticated
的用户对 cluster-info
访问权限)
然后 CA 证书通过以下验证步骤:
基本验证:使用令牌 ID 而不是 JWT 签名
公钥验证:使用提供的 --discovery-token-ca-cert-hash
。这个值来自 kubeadm init
的输出,
或者可以使用标准工具计算(哈希值是按 RFC7469 中主体公钥信息(SPKI)对象的字节计算的)
--discovery-token-ca-cert-hash
标志可以重复多次,以允许多个公钥。
作为附加验证,通过安全连接检索 CA 证书,然后与初始检索的 CA 进行比较
请注意:
通过 --discovery-token-unsafe-skip-ca-verification
标志可以跳过公钥验证;
这削弱了 kubeadm 安全模型,因为其他人可能冒充 Kubernetes 主控节点。
文件/HTTPS 发现
如果带 --discovery-file
参数调用 kubeadm join
,则使用文件发现功能;
该文件可以是本地文件或通过 HTTPS URL 下载;对于 HTTPS,主机安装的 CA 包
用于验证连接。
通过文件发现,集群 CA 证书是文件本身提供;事实上,这个发现文件是一个 kubeconfig 文件,
只设置了 server
和 certificate-authority-data
属性,
如 kubeadm join
参考文档中所述,当与集群建立连接时,kubeadm 尝试访问 cluster-info
ConfigMap,
如果可用,就使用它。
TLS 引导
知道集群信息后,kubeadm 将写入文件 bootstrap-kubelet.conf
,从而允许 kubelet 执行
TLS 引导。
TLS 引导机制使用共享令牌对 Kubernetes API 服务器进行临时身份验证,以便
为本地创建的密钥对提交证书签名请求(CSR)。
该请求会被自动批准,并且该操作保存 ca.crt
文件和 kubelet.conf
文件,用于
kubelet 加入集群,同时删除 bootstrap-kubelet.conf
。
请注意:
临时身份验证根据 kubeadm init
过程中保存的令牌进行验证(或者使用 kubeadm token
创建的其他令牌)
临时身份验证解析到 system:bootstrappers:kubeadm:default-node-token
组的一个用户成员,
该成员在 kubeadm init
过程中被授予对 CSR API 的访问权
根据 kubeadm init
过程的配置,自动 CSR 审批由 csrapprover 控制器管理
9 - 端口和协议
当你在一个有严格网络边界的环境里运行 Kubernetes,例如拥有物理网络防火墙或者拥有公有云中虚拟网络的自有数据中心,了解 Kubernetes 组件使用了哪些端口和协议是非常有用的。
控制面
协议
方向
端口范围
目的
使用者
TCP
入站
6443
Kubernetes API server
所有
TCP
入站
2379-2380
etcd server client API
kube-apiserver, etcd
TCP
入站
10250
Kubelet API
自身, 控制面
TCP
入站
10259
kube-scheduler
自身
TCP
入站
10257
kube-controller-manager
自身
尽管 etcd 的端口也列举在控制面的部分,但你也可以在外部自己托管 etcd 集群或者自定义端口。
工作节点
协议
方向
端口范围
目的
使用者
TCP
入站
10250
Kubelet API
自身, 控制面
TCP
入站
30000-32767
NodePort Services†
所有
† NodePort Services 的默认端口范围。
所有默认端口都可以重新配置。当使用自定义的端口时,你需要打开这些端口来代替这里提到的默认端口。
一个常见的例子是 API 服务器的端口有时会配置为443。或者你也可以使用默认端口,把 API 服务器放到一个监听443 端口的负载均衡器后面,并且路由所有请求到 API 服务器的默认端口。
10 - kubectl
10.1 - kubectl 命令
kubectl 命令参考
10.2 - kubectl 概述
你可以使用 Kubectl 命令行工具管理 Kubernetes 集群。
kubectl
在 $HOME/.kube
目录中查找一个名为 config
的配置文件。
你可以通过设置 KUBECONFIG 环境变量或设置
--kubeconfig
参数来指定其它 kubeconfig 文件。
本文概述了 kubectl
语法和命令操作描述,并提供了常见的示例。
有关每个命令的详细信息,包括所有受支持的参数和子命令,
请参阅 kubectl 参考文档。
有关安装说明,请参见安装 kubectl 。
语法
使用以下语法 kubectl
从终端窗口运行命令:
kubectl [ command] [ TYPE] [ NAME] [ flags]
其中 command
、TYPE
、NAME
和 flags
分别是:
flags
: 指定可选的参数。例如,可以使用 -s
或 -server
参数指定
Kubernetes API 服务器的地址和端口。
注意:
从命令行指定的参数会覆盖默认值和任何相应的环境变量。
如果你需要帮助,从终端窗口运行 kubectl help
。
操作
下表包含所有 kubectl 操作的简短描述和普通语法:
操作
语法
描述
alpha
kubectl alpha SUBCOMMAND [flags]
列出与 alpha 特性对应的可用命令,这些特性在 Kubernetes 集群中默认情况下是不启用的。
annotate
kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]
添加或更新一个或多个资源的注解。
api-resources
kubectl api-resources [flags]
列出可用的 API 资源。
api-versions
kubectl api-versions [flags]
列出可用的 API 版本。
apply
kubectl apply -f FILENAME [flags]
从文件或 stdin 对资源应用配置更改。
attach
kubectl attach POD -c CONTAINER [-i] [-t] [flags]
附加到正在运行的容器,查看输出流或与容器(stdin)交互。
auth
kubectl auth [flags] [options]
检查授权。
autoscale
kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]
自动伸缩由副本控制器管理的一组 pod。
certificate
kubectl certificate SUBCOMMAND [options]
修改证书资源。
cluster-info
kubectl cluster-info [flags]
显示有关集群中主服务器和服务的端口信息。
completion
kubectl completion SHELL [options]
为指定的 shell (bash 或 zsh)输出 shell 补齐代码。
config
kubectl config SUBCOMMAND [flags]
修改 kubeconfig 文件。有关详细信息,请参阅各个子命令。
convert
kubectl convert -f FILENAME [options]
在不同的 API 版本之间转换配置文件。配置文件可以是 YAML 或 JSON 格式。
cordon
kubectl cordon NODE [options]
将节点标记为不可调度。
cp
kubectl cp <file-spec-src> <file-spec-dest> [options]
在容器之间复制文件和目录。
create
kubectl create -f FILENAME [flags]
从文件或 stdin 创建一个或多个资源。
delete
kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags]
从文件、标准输入或指定标签选择器、名称、资源选择器或资源中删除资源。
describe
kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags]
显示一个或多个资源的详细状态。
diff
kubectl diff -f FILENAME [flags]
将 live 配置和文件或标准输入做对比 (BETA )
drain
kubectl drain NODE [options]
腾空节点以准备维护。
edit
kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags]
使用默认编辑器编辑和更新服务器上一个或多个资源的定义。
exec
kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]
对 pod 中的容器执行命令。
explain
kubectl explain [--recursive=false] [flags]
获取多种资源的文档。例如 pod, node, service 等。
expose
kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]
将副本控制器、服务或 pod 作为新的 Kubernetes 服务暴露。
get
kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags]
列出一个或多个资源。
kustomize
kubectl kustomize <dir> [flags] [options]
列出从 kustomization.yaml 文件中的指令生成的一组 API 资源。参数必须是包含文件的目录的路径,或者是 git 存储库 URL,其路径后缀相对于存储库根目录指定了相同的路径。
label
kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]
添加或更新一个或多个资源的标签。
logs
kubectl logs POD [-c CONTAINER] [--follow] [flags]
在 pod 中打印容器的日志。
options
kubectl options
全局命令行选项列表,适用于所有命令。
patch
kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags]
使用策略合并 patch 程序更新资源的一个或多个字段。
plugin
kubectl plugin [flags] [options]
提供用于与插件交互的实用程序。
port-forward
kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]
将一个或多个本地端口转发到一个 pod。
proxy
kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]
运行 Kubernetes API 服务器的代理。
replace
kubectl replace -f FILENAME
从文件或标准输入中替换资源。
rollout
kubectl rollout SUBCOMMAND [options]
管理资源的部署。有效的资源类型包括:Deployments, DaemonSets 和 StatefulSets。
run
kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server | client | none] [--overrides=inline-json] [flags]
在集群上运行指定的镜像。
scale
kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]
更新指定副本控制器的大小。
set
kubectl set SUBCOMMAND [options]
配置应用程序资源。
taint
kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]
更新一个或多个节点上的污点。
top
kubectl top [flags] [options]
显示资源(CPU/内存/存储)的使用情况。
uncordon
kubectl uncordon NODE [options]
将节点标记为可调度。
version
kubectl version [--client] [flags]
显示运行在客户端和服务器上的 Kubernetes 版本。
wait
kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options]
实验性:等待一种或多种资源的特定条件。
了解更多有关命令操作的信息,请参阅 kubectl 参考文档。
资源类型
下表列出所有受支持的资源类型及其缩写别名:
(以下输出可以通过 kubectl api-resources
获取,内容以 Kubernetes 1.19.1 版本为准。)
资源名
缩写名
API 分组
按命名空间
资源类型
bindings
true
Binding
componentstatuses
cs
false
ComponentStatus
configmaps
cm
true
ConfigMap
endpoints
ep
true
Endpoints
events
ev
true
Event
limitranges
limits
true
LimitRange
namespaces
ns
false
Namespace
nodes
no
false
Node
persistentvolumeclaims
pvc
true
PersistentVolumeClaim
persistentvolumes
pv
false
PersistentVolume
pods
po
true
Pod
podtemplates
true
PodTemplate
replicationcontrollers
rc
true
ReplicationController
resourcequotas
quota
true
ResourceQuota
secrets
true
Secret
serviceaccounts
sa
true
ServiceAccount
services
svc
true
Service
mutatingwebhookconfigurations
admissionregistration.k8s.io
false
MutatingWebhookConfiguration
validatingwebhookconfigurations
admissionregistration.k8s.io
false
ValidatingWebhookConfiguration
customresourcedefinitions
crd,crds
apiextensions.k8s.io
false
CustomResourceDefinition
apiservices
apiregistration.k8s.io
false
APIService
controllerrevisions
apps
true
ControllerRevision
daemonsets
ds
apps
true
DaemonSet
deployments
deploy
apps
true
Deployment
replicasets
rs
apps
true
ReplicaSet
statefulsets
sts
apps
true
StatefulSet
tokenreviews
authentication.k8s.io
false
TokenReview
localsubjectaccessreviews
authorization.k8s.io
true
LocalSubjectAccessReview
selfsubjectaccessreviews
authorization.k8s.io
false
SelfSubjectAccessReview
selfsubjectrulesreviews
authorization.k8s.io
false
SelfSubjectRulesReview
subjectaccessreviews
authorization.k8s.io
false
SubjectAccessReview
horizontalpodautoscalers
hpa
autoscaling
true
HorizontalPodAutoscaler
cronjobs
cj
batch
true
CronJob
jobs
batch
true
Job
certificatesigningrequests
csr
certificates.k8s.io
false
CertificateSigningRequest
leases
coordination.k8s.io
true
Lease
endpointslices
discovery.k8s.io
true
EndpointSlice
events
ev
events.k8s.io
true
Event
ingresses
ing
extensions
true
Ingress
flowschemas
flowcontrol.apiserver.k8s.io
false
FlowSchema
prioritylevelconfigurations
flowcontrol.apiserver.k8s.io
false
PriorityLevelConfiguration
ingressclasses
networking.k8s.io
false
IngressClass
ingresses
ing
networking.k8s.io
true
Ingress
networkpolicies
netpol
networking.k8s.io
true
NetworkPolicy
runtimeclasses
node.k8s.io
false
RuntimeClass
poddisruptionbudgets
pdb
policy
true
PodDisruptionBudget
podsecuritypolicies
psp
policy
false
PodSecurityPolicy
clusterrolebindings
rbac.authorization.k8s.io
false
ClusterRoleBinding
clusterroles
rbac.authorization.k8s.io
false
ClusterRole
rolebindings
rbac.authorization.k8s.io
true
RoleBinding
roles
rbac.authorization.k8s.io
true
Role
priorityclasses
pc
scheduling.k8s.io
false
PriorityClass
csidrivers
storage.k8s.io
false
CSIDriver
csinodes
storage.k8s.io
false
CSINode
storageclasses
sc
storage.k8s.io
false
StorageClass
volumeattachments
storage.k8s.io
false
VolumeAttachment
输出选项
有关如何格式化或排序某些命令的输出的信息,请使用以下部分。有关哪些命令支持各种输出选项的详细信息,请参阅kubectl 参考文档。
格式化输出
所有 kubectl
命令的默认输出格式都是人类可读的纯文本格式。要以特定格式向终端窗口输出详细信息,可以将 -o
或 --output
参数添加到受支持的 kubectl
命令中。
语法
kubectl [ command] [ TYPE] [ NAME] -o= <output_format>
根据 kubectl
操作,支持以下输出格式:
Output format
Description
-o custom-columns=<spec>
使用逗号分隔的自定义列 列表打印表。
-o custom-columns-file=<filename>
使用 <filename>
文件中的自定义列 模板打印表。
-o json
输出 JSON 格式的 API 对象
-o jsonpath=<template>
打印 jsonpath 表达式定义的字段
-o jsonpath-file=<filename>
打印 <filename>
文件中 jsonpath 表达式定义的字段。
-o name
仅打印资源名称而不打印任何其他内容。
-o wide
以纯文本格式输出,包含任何附加信息。对于 pod 包含节点名。
-o yaml
输出 YAML 格式的 API 对象。
示例
在此示例中,以下命令将单个 pod 的详细信息输出为 YAML 格式的对象:
kubectl get pod web-pod-13je7 -o yaml
请记住:有关每个命令支持哪种输出格式的详细信息,请参阅 kubectl 参考文档。
自定义列
要定义自定义列并仅将所需的详细信息输出到表中,可以使用该 custom-columns 选项。你可以选择内联定义自定义列或使用模板文件:-o=custom-columns=<spec>
或 -o=custom-columns-file=<filename>
。
示例
内联:
kubectl get pods <pod-name> -o custom-columns= NAME:.metadata.name,RSRC:.metadata.resourceVersion
模板文件:
kubectl get pods <pod-name> -o custom-columns-file= template.txt
其中,template.txt
文件包含:
NAME RSRC
metadata.name metadata.resourceVersion
运行任何一个命令的结果类似于:
NAME RSRC
submit-queue 610995
Server-side 列
kubectl
支持从服务器接收关于对象的特定列信息。
这意味着对于任何给定的资源,服务器将返回与该资源相关的列和行,以便客户端打印。
通过让服务器封装打印的细节,这允许在针对同一集群使用的客户端之间提供一致的人类可读输出。
此功能默认启用。要禁用它,请将该 --server-print=false
参数添加到 kubectl get
命令中。
例子:
要打印有关 pod 状态的信息,请使用如下命令:
kubectl get pods <pod-name> --server-print= false
输出类似于:
排序列表对象
要将对象排序后输出到终端窗口,可以将 --sort-by
参数添加到支持的 kubectl
命令。通过使用 --sort-by
参数指定任何数字或字符串字段来对对象进行排序。要指定字段,请使用 jsonpath 表达式。
语法
kubectl [ command] [ TYPE] [ NAME] --sort-by= <jsonpath_exp>
示例
要打印按名称排序的 pod 列表,请运行:
kubectl get pods --sort-by= .metadata.name
示例:常用操作
使用以下示例集来帮助你熟悉运行常用 kubectl 操作:
kubectl apply
- 以文件或标准输入为准应用或更新资源。
# 使用 example-service.yaml 中的定义创建服务。
kubectl apply -f example-service.yaml
# 使用 example-controller.yaml 中的定义创建 replication controller。
kubectl apply -f example-controller.yaml
# 使用 <directory> 路径下的任意 .yaml, .yml, 或 .json 文件 创建对象。
kubectl apply -f <directory>
kubectl get
- 列出一个或多个资源。
# 以纯文本输出格式列出所有 pod。
kubectl get pods
# 以纯文本输出格式列出所有 pod,并包含附加信息(如节点名)。
kubectl get pods -o wide
# 以纯文本输出格式列出具有指定名称的副本控制器。提示:你可以使用别名 'rc' 缩短和替换 'replicationcontroller' 资源类型。
kubectl get replicationcontroller <rc-name>
# 以纯文本输出格式列出所有副本控制器和服务。
kubectl get rc,services
# 以纯文本输出格式列出所有守护程序集,包括未初始化的守护程序集。
kubectl get ds --include-uninitialized
# 列出在节点 server01 上运行的所有 pod
kubectl get pods --field-selector= spec.nodeName= server01
kubectl describe
- 显示一个或多个资源的详细状态,默认情况下包括未初始化的资源。
# 显示名称为 <node-name> 的节点的详细信息。
kubectl describe nodes <node-name>
# 显示名为 <pod-name> 的 pod 的详细信息。
kubectl describe pods/<pod-name>
# 显示由名为 <rc-name> 的副本控制器管理的所有 pod 的详细信息。
# 记住:副本控制器创建的任何 pod 都以复制控制器的名称为前缀。
kubectl describe pods <rc-name>
# 描述所有的 pod,不包括未初始化的 pod
kubectl describe pods
说明:
kubectl get
命令通常用于检索同一资源类型的一个或多个资源。
它具有丰富的参数,允许你使用 -o
或 --output
参数自定义输出格式。你可以指定 -w
或 --watch
参数以开始观察特定对象的更新。
kubectl describe
命令更侧重于描述指定资源的许多相关方面。它可以调用对 API 服务器
的多个 API 调用来为用户构建视图。
例如,该 kubectl describe node
命令不仅检索有关节点的信息,还检索在其上运行的 pod 的摘要,为节点生成的事件等。
kubectl delete
- 从文件、stdin 或指定标签选择器、名称、资源选择器或资源中删除资源。
# 使用 pod.yaml 文件中指定的类型和名称删除 pod。
kubectl delete -f pod.yaml
# 删除所有带有 '<label-key>=<label-value>' 标签的 Pod 和服务。
kubectl delete pods,services -l <label-key>= <label-value>
# 删除所有 pod,包括未初始化的 pod。
kubectl delete pods --all
kubectl exec
- 对 pod 中的容器执行命令。
# 从 pod <pod-name> 中获取运行 'date' 的输出。默认情况下,输出来自第一个容器。
kubectl exec <pod-name> -- date
# 运行输出 'date' 获取在容器的 <container-name> 中 pod <pod-name> 的输出。
kubectl exec <pod-name> -c <container-name> -- date
# 获取一个交互 TTY 并运行 /bin/bash <pod-name >。默认情况下,输出来自第一个容器。
kubectl exec -ti <pod-name> -- /bin/bash
kubectl logs
- 打印 Pod 中容器的日志。
# 从 pod 返回日志快照。
kubectl logs <pod-name>
# 从 pod <pod-name> 开始流式传输日志。这类似于 'tail -f' Linux 命令。
kubectl logs -f <pod-name>
示例:创建和使用插件
使用以下示例来帮助你熟悉编写和使用 kubectl
插件:
# 用任何语言创建一个简单的插件,并为生成的可执行文件命名
# 以前缀 "kubectl-" 开始
cat ./kubectl-hello
#!/bin/sh
# 这个插件打印单词 "hello world"
echo "hello world"
这个插件写好了,把它变成可执行的:
sudo chmod a+x ./kubectl-hello
# 并将其移动到路径中的某个位置
sudo mv ./kubectl-hello /usr/local/bin
sudo chown root:root /usr/local/bin
# 你现在已经创建并"安装了"一个 kubectl 插件。
# 你可以开始使用这个插件,从 kubectl 调用它,就像它是一个常规命令一样
kubectl hello
hello world
# 你可以"卸载"一个插件,只需从你的路径中删除它
sudo rm /usr/local/bin/kubectl-hello
为了查看可用的所有 kubectl
插件,你可以使用 kubectl plugin list
子命令:
输出类似于:
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-bar
kubectl plugin list
指令也可以向你告警哪些插件被运行,或是被其它插件覆盖了,例如:
sudo chmod -x /usr/local/bin/kubectl-foo # 删除执行权限
kubectl plugin list
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
- warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
/usr/local/bin/kubectl-bar
error: one plugin warning was found
你可以将插件视为在现有 kubectl 命令之上构建更复杂功能的一种方法:
接下来的几个示例假设你已经将 kubectl-whoami
设置为以下内容:
#!/bin/bash
#这个插件利用 `kubectl config` 命令基于当前所选上下文输出当前用户的信息
kubectl config view --template= '{{ range .contexts }}{{ if eq .name "' $( kubectl config current-context) '" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
运行以上命令将为你提供一个输出,其中包含 KUBECONFIG 文件中当前上下文的用户:
#!/bin/bash
# 使文件成为可执行的
sudo chmod +x ./kubectl-whoami
# 然后移动到你的路径中
sudo mv ./kubectl-whoami /usr/local/bin
kubectl whoami
Current user: plugins-user
要了解关于插件的更多信息,请查看示例 cli 插件 。
接下来
10.3 - kubectl
简介
kubectl 管理控制 Kubernetes 集群。
获取更多信息,请访问 kubectl 概述 。
kubectl [flags]
选项
--add-dir-header
设置为 true 表示添加文件目录到日志信息头中
--alsologtostderr
表示将日志输出到文件的同时输出到 stderr
--as string
以指定用户的身份执行操作
--as-group stringArray
模拟指定的组来执行操作,可以使用这个标志来指定多个组。
--azure-container-registry-config string
包含 Azure 容器仓库配置信息的文件的路径。
--cache-dir string 默认值: "$HOME/.kube/cache"
默认缓存目录
--certificate-authority string
指向证书机构的 cert 文件路径
--client-certificate string
TLS 使用的客户端证书路径
--client-key string
TLS 使用的客户端密钥文件路径
--cloud-provider-gce-l7lb-src-cidrs cidrs 默认值: 130.211.0.0/22,35.191.0.0/16
在 GCE 防火墙中开放的 CIDR,用来进行 L7 LB 流量代理和健康检查。
--cloud-provider-gce-lb-src-cidrs cidrs 默认值: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16
在 GCE 防火墙中开放的 CIDR,用来进行 L4 LB 流量代理和健康检查。
--cluster string
要使用的 kubeconfig 集群的名称
--context string
要使用的 kubeconfig 上下文的名称
--default-not-ready-toleration-seconds int 默认值: 300
表示 `notReady` 状态的容忍度秒数:默认情况下,`NoExecute` 被添加到尚未具有此容忍度的每个 Pod 中。
--default-unreachable-toleration-seconds int 默认值: 300
表示 `unreachable` 状态的容忍度秒数:默认情况下,`NoExecute` 被添加到尚未具有此容忍度的每个 Pod 中。
-h, --help
kubectl 操作的帮助命令
--insecure-skip-tls-verify
设置为 true,则表示不会检查服务器证书的有效性。这样会导致您的 HTTPS 连接不安全。
--kubeconfig string
CLI 请求使用的 kubeconfig 配置文件的路径。
--log-backtrace-at traceLocation 默认值: 0
当日志机制运行到指定文件的指定行(file:N)时,打印调用堆栈信息
--log-dir string
如果不为空,则将日志文件写入此目录
--log-file string
如果不为空,则将使用此日志文件
--log-file-max-size uint 默认值: 1800
定义日志文件的最大尺寸。单位为兆字节。如果值设置为 0,则表示日志文件大小不受限制。
--log-flush-frequency duration 默认值: 5s
两次日志刷新操作之间的最长时间(秒)
--logtostderr 默认值: true
日志输出到 stderr 而不是文件中
--match-server-version
要求客户端版本和服务端版本相匹配
-n, --namespace string
如果存在,CLI 请求将使用此命名空间
--one-output
如果为 true,则只将日志写入初始严重级别(而不是同时写入所有较低的严重级别)。
--password string
API 服务器进行基本身份验证的密码
--profile string 默认值: "none"
要记录的性能指标的名称。可取 (none|cpu|heap|goroutine|threadcreate|block|mutex) 其中之一。
--profile-output string 默认值: "profile.pprof"
用于转储所记录的性能信息的文件名
--request-timeout string 默认值: "0"
放弃单个服务器请求之前的等待时间,非零值需要包含相应时间单位(例如:1s、2m、3h)。零值则表示不做超时要求。
-s, --server string
Kubernetes API 服务器的地址和端口
--skip-headers
设置为 true 则表示跳过在日志消息中出现 header 前缀信息
--skip-log-headers
设置为 true 则表示在打开日志文件时跳过 header 信息
--stderrthreshold severity 默认值: 2
等于或高于此阈值的日志将输出到标准错误输出(stderr)
--token string
用于对 API 服务器进行身份认证的持有者令牌
--user string
指定使用 kubeconfig 配置文件中的用户名
--username string
用于 API 服务器的基本身份验证的用户名
-v, --v Level
指定输出日志的日志详细级别
--version version[=true]
打印 kubectl 版本信息并退出
--vmodule moduleSpec
以逗号分隔的 pattern=N 设置列表,用于过滤文件的日志记录
环境变量
KUBECONFIG
kubectl 的配置 ("kubeconfig") 文件的路径。默认值: "$HOME/.kube/config"
KUBECTL_COMMAND_HEADERS
设置为 false 时,关闭用于详细说明被调用的 kubectl 命令的额外 HTTP 标头 (Kubernetes 版本为 v1.22 或者更高)
另请参见
10.4 - JSONPath 支持
Kubectl 支持 JSONPath 模板。
JSONPath 模板由 {} 包起来的 JSONPath 表达式组成。Kubectl 使用 JSONPath 表达式来过滤 JSON 对象中的特定字段并格式化输出。除了原始的 JSONPath 模板语法,以下函数和语法也是有效的:
使用双引号将 JSONPath 表达式内的文本引起来。
使用 range
,end
运算符来迭代列表。
使用负片索引后退列表。负索引不会“环绕”列表,并且只要 -index + listLength> = 0
就有效。
给定 JSON 输入:
{
"kind" : "List" ,
"items" :[
{
"kind" :"None" ,
"metadata" :{"name" :"127.0.0.1" },
"status" :{
"capacity" :{"cpu" :"4" },
"addresses" :[{"type" : "LegacyHostIP" , "address" :"127.0.0.1" }]
}
},
{
"kind" :"None" ,
"metadata" :{"name" :"127.0.0.2" },
"status" :{
"capacity" :{"cpu" :"8" },
"addresses" :[
{"type" : "LegacyHostIP" , "address" :"127.0.0.2" },
{"type" : "another" , "address" :"127.0.0.3" }
]
}
}
],
"users" :[
{
"name" : "myself" ,
"user" : {}
},
{
"name" : "e2e" ,
"user" : {"username" : "admin" , "password" : "secret" }
}
]
}
函数
描述
示例
结果
text
纯文本
kind is {.kind}
kind is List
@
当前对象
{@}
与输入相同
.
or []
子运算符
{.kind}
, {['kind']}
or {['name\.type']}
List
..
递归下降
{..name}
127.0.0.1 127.0.0.2 myself e2e
*
通配符。获取所有对象
{.items[*].metadata.name}
[127.0.0.1 127.0.0.2]
[start:end :step]
下标运算符
{.users[0].name}
myself
[,]
并集运算符
{.items[*]['metadata.name', 'status.capacity']}
127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]
?()
过滤
{.users[?(@.name=="e2e")].user.password}
secret
range
, end
迭代列表
{range .items[*]}[{.metadata.name}, {.status.capacity}] {end}
[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]
''
引用解释执行字符串
{range .items[*]}{.metadata.name}{'\t'}{end}
127.0.0.1 127.0.0.2
使用 kubectl
和 JSONPath 表达式的示例:
kubectl get pods -o json
kubectl get pods -o= jsonpath = '{@}'
kubectl get pods -o= jsonpath = '{.items[0]}'
kubectl get pods -o= jsonpath = '{.items[0].metadata.name}'
kubectl get pods -o= jsonpath = "{.items[*]['metadata.name', 'status.capacity']}"
kubectl get pods -o= jsonpath = '{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}'
说明: 在 Windows 上,对于任何包含空格的 JSONPath 模板,您必须使用双引号(不是上面 bash 所示的单引号)。
反过来,这意味着您必须在模板中的所有文字周围使用单引号或转义的双引号。
例如:
C:\ > kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}"
C:\ > kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"
说明: 不支持 JSONPath 正则表达式。如需使用正则表达式进行匹配操作,您可以使用如 jq
之类的工具。
# kubectl 的 JSONpath 输出不支持正则表达式
# 下面的命令不会生效
kubectl get pods -o jsonpath = '{.items[?(@.metadata.name=~/^test$/)].metadata.name}'
# 下面的命令可以获得所需的结果
kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).spec.containers[].image'
10.5 - kubectl 备忘单
本页列举了常用的 “kubectl” 命令和标志
Kubectl 自动补全
BASH
source <( kubectl completion bash) # 在 bash 中设置当前 shell 的自动补全,要先安装 bash-completion 包。
echo "source <(kubectl completion bash)" >> ~/.bashrc # 在您的 bash shell 中永久的添加自动补全
您还可以为 kubectl
使用一个速记别名,该别名也可以与 completion 一起使用:
alias k = kubectl
complete -F __start_kubectl k
ZSH
source <( kubectl completion zsh) # 在 zsh 中设置当前 shell 的自动补全
echo "[[ $commands [kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # 在您的 zsh shell 中永久的添加自动补全
Kubectl 上下文和配置
设置 kubectl
与哪个 Kubernetes 集群进行通信并修改配置信息。
查看使用 kubeconfig 跨集群授权访问
文档获取配置文件详细信息。
kubectl config view # 显示合并的 kubeconfig 配置。
# 同时使用多个 kubeconfig 文件并查看合并的配置
KUBECONFIG = ~/.kube/config:~/.kube/kubconfig2 kubectl config view
# 获取 e2e 用户的密码
kubectl config view -o jsonpath = '{.users[?(@.name == "e2e")].user.password}'
kubectl config view -o jsonpath = '{.users[].name}' # 显示第一个用户
kubectl config view -o jsonpath = '{.users[*].name}' # 获取用户列表
kubectl config get-contexts # 显示上下文列表
kubectl config current-context # 展示当前所处的上下文
kubectl config use-context my-cluster-name # 设置默认的上下文为 my-cluster-name
# 添加新的用户配置到 kubeconf 中,使用 basic auth 进行身份认证
kubectl config set-credentials kubeuser/foo.kubernetes.com --username= kubeuser --password= kubepassword
# 在指定上下文中持久性地保存名字空间,供所有后续 kubectl 命令使用
kubectl config set-context --current --namespace= ggckad-s2
# 使用特定的用户名和名字空间设置上下文
kubectl config set-context gce --user= cluster-admin --namespace= foo \
&& kubectl config use-context gce
kubectl config unset users.foo # 删除用户 foo
Kubectl apply
apply
通过定义 Kubernetes 资源的文件来管理应用。
它通过运行 kubectl apply
在集群中创建和更新资源。
这是在生产中管理 Kubernetes 应用的推荐方法。
参见 Kubectl 文档 。
创建对象
Kubernetes 配置可以用 YAML 或 JSON 定义。可以使用的文件扩展名有
.yaml
、.yml
和 .json
。
kubectl apply -f ./my-manifest.yaml # 创建资源
kubectl apply -f ./my1.yaml -f ./my2.yaml # 使用多个文件创建
kubectl apply -f ./dir # 基于目录下的所有清单文件创建资源
kubectl apply -f https://git.io/vPieo # 从 URL 中创建资源
kubectl create deployment nginx --image= nginx # 启动单实例 nginx
# 创建一个打印 “Hello World” 的 Job
kubectl create job hello --image= busybox -- echo "Hello World"
# 创建一个打印 “Hello World” 间隔1分钟的 CronJob
kubectl create cronjob hello --image= busybox --schedule= "*/1 * * * *" -- echo "Hello World"
kubectl explain pods # 获取 pod 清单的文档说明
# 从标准输入创建多个 YAML 对象
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "1000000"
---
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep-less
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "1000"
EOF
# 创建有多个 key 的 Secret
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: $(echo -n "s33msi4" | base64 -w0)
username: $(echo -n "jane" | base64 -w0)
EOF
查看和查找资源
# get 命令的基本输出
kubectl get services # 列出当前命名空间下的所有 services
kubectl get pods --all-namespaces # 列出所有命名空间下的全部的 Pods
kubectl get pods -o wide # 列出当前命名空间下的全部 Pods,并显示更详细的信息
kubectl get deployment my-dep # 列出某个特定的 Deployment
kubectl get pods # 列出当前命名空间下的全部 Pods
kubectl get pod my-pod -o yaml # 获取一个 pod 的 YAML
# describe 命令的详细输出
kubectl describe nodes my-node
kubectl describe pods my-pod
# 列出当前名字空间下所有 Services,按名称排序
kubectl get services --sort-by= .metadata.name
# 列出 Pods,按重启次数排序
kubectl get pods --sort-by= '.status.containerStatuses[0].restartCount'
# 列举所有 PV 持久卷,按容量排序
kubectl get pv --sort-by= .spec.capacity.storage
# 获取包含 app=cassandra 标签的所有 Pods 的 version 标签
kubectl get pods --selector= app = cassandra -o \
jsonpath = '{.items[*].metadata.labels.version}'
# 检索带有 “.” 键值,例: 'ca.crt'
kubectl get configmap myconfig \
-o jsonpath = '{.data.ca\.crt}'
# 获取所有工作节点(使用选择器以排除标签名称为 'node-role.kubernetes.io/master' 的结果)
kubectl get node --selector= '!node-role.kubernetes.io/master'
# 获取当前命名空间中正在运行的 Pods
kubectl get pods --field-selector= status.phase= Running
# 获取全部节点的 ExternalIP 地址
kubectl get nodes -o jsonpath = '{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'
# 列出属于某个特定 RC 的 Pods 的名称
# 在转换对于 jsonpath 过于复杂的场合,"jq" 命令很有用;可以在 https://stedolan.github.io/jq/ 找到它。
sel = ${ $( kubectl get rc my-rc --output= json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"' ) %?}
echo $( kubectl get pods --selector= $sel --output= jsonpath ={ .items..metadata.name} )
# 显示所有 Pods 的标签(或任何其他支持标签的 Kubernetes 对象)
kubectl get pods --show-labels
# 检查哪些节点处于就绪状态
JSONPATH = '{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
&& kubectl get nodes -o jsonpath = " $JSONPATH " | grep "Ready=True"
# 不使用外部工具来输出解码后的 Secret
kubectl get secret my-secret -o go-template= '{{range $k,$v := .data}}{{"### "}}{{$k}}{{"\n"}}{{$v|base64decode}}{{"\n\n"}}{{end}}'
# 列出被一个 Pod 使用的全部 Secret
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
# 列举所有 Pods 中初始化容器的容器 ID(containerID)
# 可用于在清理已停止的容器时避免删除初始化容器
kubectl get pods --all-namespaces -o jsonpath = '{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
# 列出事件(Events),按时间戳排序
kubectl get events --sort-by= .metadata.creationTimestamp
# 比较当前的集群状态和假定某清单被应用之后的集群状态
kubectl diff -f ./my-manifest.yaml
# 生成一个句点分隔的树,其中包含为节点返回的所有键
# 在复杂的嵌套JSON结构中定位键时非常有用
kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
# 生成一个句点分隔的树,其中包含为pod等返回的所有键
kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
# 假设你的 Pods 有默认的容器和默认的名字空间,并且支持 'env' 命令,可以使用以下脚本为所有 Pods 生成 ENV 变量。
# 该脚本也可用于在所有的 Pods 里运行任何受支持的命令,而不仅仅是 'env'。
for pod in $( kubectl get po --output= jsonpath ={ .items..metadata.name} ) ; do echo $pod && kubectl exec -it $pod -- env; done
更新资源
kubectl set image deployment/frontend www = image:v2 # 滚动更新 "frontend" Deployment 的 "www" 容器镜像
kubectl rollout history deployment/frontend # 检查 Deployment 的历史记录,包括版本
kubectl rollout undo deployment/frontend # 回滚到上次部署版本
kubectl rollout undo deployment/frontend --to-revision= 2 # 回滚到特定部署版本
kubectl rollout status -w deployment/frontend # 监视 "frontend" Deployment 的滚动升级状态直到完成
kubectl rollout restart deployment/frontend # 轮替重启 "frontend" Deployment
cat pod.json | kubectl replace -f - # 通过传入到标准输入的 JSON 来替换 Pod
# 强制替换,删除后重建资源。会导致服务不可用。
kubectl replace --force -f ./pod.json
# 为多副本的 nginx 创建服务,使用 80 端口提供服务,连接到容器的 8000 端口。
kubectl expose rc nginx --port= 80 --target-port= 8000
# 将某单容器 Pod 的镜像版本(标签)更新到 v4
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -
kubectl label pods my-pod new-label= awesome # 添加标签
kubectl annotate pods my-pod icon-url= http://goo.gl/XXBTWq # 添加注解
kubectl autoscale deployment foo --min= 2 --max= 10 # 对 "foo" Deployment 自动伸缩容
部分更新资源
# 部分更新某节点
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'
# 更新容器的镜像;spec.containers[*].name 是必须的。因为它是一个合并性质的主键。
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
# 使用带位置数组的 JSON patch 更新容器的镜像
kubectl patch pod valid-pod --type= 'json' -p= '[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'
# 使用带位置数组的 JSON patch 禁用某 Deployment 的 livenessProbe
kubectl patch deployment valid-deployment --type json -p= '[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'
# 在带位置数组中添加元素
kubectl patch sa default --type= 'json' -p= '[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
编辑资源
使用你偏爱的编辑器编辑 API 资源。
kubectl edit svc/docker-registry # 编辑名为 docker-registry 的服务
KUBE_EDITOR = "nano" kubectl edit svc/docker-registry # 使用其他编辑器
对资源进行伸缩
kubectl scale --replicas= 3 rs/foo # 将名为 'foo' 的副本集伸缩到 3 副本
kubectl scale --replicas= 3 -f foo.yaml # 将在 "foo.yaml" 中的特定资源伸缩到 3 个副本
kubectl scale --current-replicas= 2 --replicas= 3 deployment/mysql # 如果名为 mysql 的 Deployment 的副本当前是 2,那么将它伸缩到 3
kubectl scale --replicas= 5 rc/foo rc/bar rc/baz # 伸缩多个副本控制器
删除资源
kubectl delete -f ./pod.json # 删除在 pod.json 中指定的类型和名称的 Pod
kubectl delete pod,service baz foo # 删除名称为 "baz" 和 "foo" 的 Pod 和服务
kubectl delete pods,services -l name = myLabel # 删除包含 name=myLabel 标签的 pods 和服务
kubectl -n my-ns delete pod,svc --all # 删除在 my-ns 名字空间中全部的 Pods 和服务
# 删除所有与 pattern1 或 pattern2 awk 模式匹配的 Pods
kubectl get pods -n mynamespace --no-headers= true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod
与运行中的 Pods 进行交互
kubectl logs my-pod # 获取 pod 日志(标准输出)
kubectl logs -l name = myLabel # 获取含 name=myLabel 标签的 Pods 的日志(标准输出)
kubectl logs my-pod --previous # 获取上个容器实例的 pod 日志(标准输出)
kubectl logs my-pod -c my-container # 获取 Pod 容器的日志(标准输出, 多容器场景)
kubectl logs -l name = myLabel -c my-container # 获取含 name=myLabel 标签的 Pod 容器日志(标准输出, 多容器场景)
kubectl logs my-pod -c my-container --previous # 获取 Pod 中某容器的上个实例的日志(标准输出, 多容器场景)
kubectl logs -f my-pod # 流式输出 Pod 的日志(标准输出)
kubectl logs -f my-pod -c my-container # 流式输出 Pod 容器的日志(标准输出, 多容器场景)
kubectl logs -f -l name = myLabel --all-containers # 流式输出含 name=myLabel 标签的 Pod 的所有日志(标准输出)
kubectl run -i --tty busybox --image= busybox -- sh # 以交互式 Shell 运行 Pod
kubectl run nginx --image= nginx -n mynamespace # 在指定名字空间中运行 nginx Pod
kubectl run nginx --image= nginx # 运行 ngins Pod 并将其规约写入到名为 pod.yaml 的文件
--dry-run= client -o yaml > pod.yaml
kubectl attach my-pod -i # 挂接到一个运行的容器中
kubectl port-forward my-pod 5000:6000 # 在本地计算机上侦听端口 5000 并转发到 my-pod 上的端口 6000
kubectl exec my-pod -- ls / # 在已有的 Pod 中运行命令(单容器场景)
kubectl exec --stdin --tty my-pod -- /bin/sh # 使用交互 shell 访问正在运行的 Pod (一个容器场景)
kubectl exec my-pod -c my-container -- ls / # 在已有的 Pod 中运行命令(多容器场景)
kubectl top pod POD_NAME --containers # 显示给定 Pod 和其中容器的监控数据
kubectl top pod POD_NAME --sort-by= cpu # 显示给定 Pod 的指标并且按照 'cpu' 或者 'memory' 排序
与 Deployments 和 Services 进行交互
kubectl logs deploy/my-deployment # 获取一个 Deployment 的 Pod 的日志(单容器例子)
kubectl logs deploy/my-deployment -c my-container # 获取一个 Deployment 的 Pod 的日志(多容器例子)
kubectl port-forward svc/my-service 5000 # 侦听本地端口 5000 并转发到 Service 后端端口 5000
kubectl port-forward svc/my-service 5000:my-service-port # 侦听本地端口 5000 并转发到名字为 <my-service-port> 的 Service 目标端口
kubectl port-forward deploy/my-deployment 5000:6000 # 侦听本地端口 5000 并转发到 <my-deployment> 创建的 Pod 里的端口 6000
kubectl exec deploy/my-deployment -- ls # 在 Deployment 里的第一个 Pod 的第一个容器里运行命令(单容器和多容器例子)
与节点和集群进行交互
kubectl cordon my-node # 标记 my-node 节点为不可调度
kubectl drain my-node # 对 my-node 节点进行清空操作,为节点维护做准备
kubectl uncordon my-node # 标记 my-node 节点为可以调度
kubectl top node my-node # 显示给定节点的度量值
kubectl cluster-info # 显示主控节点和服务的地址
kubectl cluster-info dump # 将当前集群状态转储到标准输出
kubectl cluster-info dump --output-directory= /path/to/cluster-state # 将当前集群状态输出到 /path/to/cluster-state
# 如果已存在具有指定键和效果的污点,则替换其值为指定值。
kubectl taint nodes foo dedicated = special-user:NoSchedule
资源类型
列出所支持的全部资源类型和它们的简称、API 组 , 是否是名字空间作用域 和 Kind 。
用于探索 API 资源的其他操作:
kubectl api-resources --namespaced= true # 所有命名空间作用域的资源
kubectl api-resources --namespaced= false # 所有非命名空间作用域的资源
kubectl api-resources -o name # 用简单格式列举所有资源(仅显示资源名称)
kubectl api-resources -o wide # 用扩展格式列举所有资源(又称 "wide" 格式)
kubectl api-resources --verbs= list,get # 支持 "list" 和 "get" 请求动词的所有资源
kubectl api-resources --api-group= extensions # "extensions" API 组中的所有资源
格式化输出
要以特定格式将详细信息输出到终端窗口,将 -o
(或者 --output
)参数添加到支持的 kubectl
命令中。
输出格式
描述
-o=custom-columns=<spec>
使用逗号分隔的自定义列来打印表格
-o=custom-columns-file=<filename>
使用 <filename>
文件中的自定义列模板打印表格
-o=json
输出 JSON 格式的 API 对象
-o=jsonpath=<template>
打印 jsonpath 表达式中定义的字段
-o=jsonpath-file=<filename>
打印在 <filename>
文件中定义的 jsonpath 表达式所指定的字段。
-o=name
仅打印资源名称而不打印其他内容
-o=wide
以纯文本格式输出额外信息,对于 Pod 来说,输出中包含了节点名称
-o=yaml
输出 YAML 格式的 API 对象
使用 -o=custom-columns
的示例:
# 集群中运行着的所有镜像
kubectl get pods -A -o= custom-columns= 'DATA:spec.containers[*].image'
# 列举 default 名字空间中运行的所有镜像,按 Pod 分组
kubectl get pods --namespace default --output= custom-columns= "NAME:.metadata.name,IMAGE:.spec.containers[*].image"
# 除 "k8s.gcr.io/coredns:1.6.2" 之外的所有镜像
kubectl get pods -A -o= custom-columns= 'DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'
# 输出 metadata 下面的所有字段,无论 Pod 名字为何
kubectl get pods -A -o= custom-columns= 'DATA:metadata.*'
有关更多示例,请参看 kubectl 参考文档 。
Kubectl 日志输出详细程度和调试
Kubectl 日志输出详细程度是通过 -v
或者 --v
来控制的,参数后跟一个数字表示日志的级别。
Kubernetes 通用的日志习惯和相关的日志级别在
这里 有相应的描述。
详细程度
描述
--v=0
用于那些应该 始终 对运维人员可见的信息,因为这些信息一般很有用。
--v=1
如果您不想要看到冗余信息,此值是一个合理的默认日志级别。
--v=2
输出有关服务的稳定状态的信息以及重要的日志消息,这些信息可能与系统中的重大变化有关。这是建议大多数系统设置的默认日志级别。
--v=3
包含有关系统状态变化的扩展信息。
--v=4
包含调试级别的冗余信息。
--v=5
跟踪级别的详细程度。
--v=6
显示所请求的资源。
--v=7
显示 HTTP 请求头。
--v=8
显示 HTTP 请求内容。
--v=9
显示 HTTP 请求内容而且不截断内容。
接下来
10.6 - kubectl 的用法约定
kubectl
的推荐用法约定。
在可重用脚本中使用 kubectl
对于脚本中的稳定输出:
请求一个面向机器的输出格式,例如 -o name
、-o json
、-o yaml
、-o go template
或 -o jsonpath
。
完全限定版本。例如 jobs.v1.batch/myjob
。这将确保 kubectl 不会使用其默认版本,该版本会随着时间的推移而更改。
不要依赖上下文、首选项或其他隐式状态。
最佳实践
kubectl run
若希望 kubectl run
满足基础设施即代码的要求:
使用特定版本的标签标记镜像,不要将该标签移动到新版本。例如,使用 :v1234
、v1.2.3
、r03062016-1-4
,而不是 :latest
(有关详细信息,请参阅配置的最佳实践 )。
使用基于版本控制的脚本来运行包含大量参数的镜像。
对于无法通过 kubectl run
参数来表示的功能特性,使用基于源码控制的配置文件,以记录要使用的功能特性。
你可以使用 --dry-run=client
参数来预览而不真正提交即将下发到集群的对象实例:
kubectl apply
您可以使用 kubectl apply
命令创建或更新资源。有关使用 kubectl apply 更新资源的详细信息,请参阅 Kubectl 文档 。
10.7 - 适用于 Docker 用户的 kubectl
您可以使用 Kubernetes 命令行工具 kubectl
与 API 服务器进行交互。如果您熟悉 Docker 命令行工具,则使用 kubectl 非常简单。但是,Docker 命令和 kubectl 命令之间有一些区别。以下显示了 Docker 子命令,并描述了等效的 kubectl
命令。
docker run
要运行 nginx 部署并将其暴露,请参见kubectl create deployment
docker:
docker run -d --restart= always -e DOMAIN = cluster --name nginx-app -p 80:80 nginx
55c103fa129692154a7652490236fee9be47d70a8dd562281ae7d2f9a339a6db
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 9 seconds ago Up 9 seconds 0.0.0.0:80->80/tcp nginx-app
kubectl:
# 启动运行 nginx 的 Pod
kubectl create deployment --image= nginx nginx-app
deployment.apps/nginx-app created
# add env to nginx-app
kubectl set env deployment/nginx-app DOMAIN = cluster
deployment.apps/nginx-app env updated
说明:
kubectl
命令打印创建或突变资源的类型和名称,然后可以在后续命令中使用。部署后,您可以公开新服务。
# 通过服务公开端口
kubectl expose deployment nginx-app --port= 80 --name= nginx-http
service "nginx-http" exposed
在 kubectl 命令中,我们创建了一个 Deployment ,这将保证有 N 个运行 nginx 的 pod(N 代表 spec 中声明的 replica 数,默认为 1)。我们还创建了一个 service ,其选择器与容器标签匹配。查看使用服务访问群集中的应用程序 获取更多信息。
默认情况下镜像会在后台运行,与 docker run -d ...
类似,如果您想在前台运行,使用 kubectl run
在前台运行 Pod:
kubectl run [ -i] [ --tty] --attach <name> --image= <image>
与 docker run ...
不同的是,如果指定了 --attach
,我们将连接到 stdin
,stdout
和 stderr
,而不能控制具体连接到哪个输出流(docker -a ...
)。要从容器中退出,可以输入 Ctrl + P,然后按 Ctrl + Q。
因为我们使用 Deployment 启动了容器,如果您终止连接到的进程(例如 ctrl-c
),容器将会重启,这跟 docker run -it
不同。
如果想销毁该 Deployment(和它的 pod),您需要运行 kubectl delete deployment <name>
。
docker ps
如何列出哪些正在运行?查看 kubectl get 。
使用 docker 命令:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
14636241935f ubuntu:16.04 "echo test" 5 seconds ago Exited (0) 5 seconds ago cocky_fermi
55c103fa1296 nginx "nginx -g 'daemon of…" About a minute ago Up About a minute 0.0.0.0:80->80/tcp nginx-app
使用 kubectl 命令:
NAME READY STATUS RESTARTS AGE
nginx-app-8df569cb7-4gd89 1/1 Running 0 3m
ubuntu 0/1 Completed 0 20s
docker attach
如何连接到已经运行在容器中的进程?查看 kubectl attach 。
使用 docker 命令:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 5 minutes ago Up 5 minutes 0.0.0.0:80->80/tcp nginx-app
docker attach 55c103fa1296
...
kubectl:
NAME READY STATUS RESTARTS AGE
nginx-app-5jyvm 1/1 Running 0 10m
kubectl attach -it nginx-app-5jyvm
...
要从容器中分离,可以输入 Ctrl + P,然后按 Ctrl + Q。
docker exec
如何在容器中执行命令?查看 kubectl exec 。
使用 docker 命令:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 6 minutes ago Up 6 minutes 0.0.0.0:80->80/tcp nginx-app
docker exec 55c103fa1296 cat /etc/hostname
55c103fa1296
使用 kubectl 命令:
NAME READY STATUS RESTARTS AGE
nginx-app-5jyvm 1/1 Running 0 10m
kubectl exec nginx-app-5jyvm -- cat /etc/hostname
nginx-app-5jyvm
执行交互式命令怎么办?
使用 docker 命令:
docker exec -ti 55c103fa1296 /bin/sh
# exit
kubectl:
kubectl exec -ti nginx-app-5jyvm -- /bin/sh
# exit
更多信息请查看获取运行中容器的 Shell 环境 。
docker logs
如何查看运行中进程的 stdout/stderr?查看 kubectl logs 。
使用 docker 命令:
192.168.9.1 - - [14/Jul/2015:01:04:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
192.168.9.1 - - [14/Jul/2015:01:04:03 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
使用 kubectl 命令:
kubectl logs -f nginx-app-zibvs
10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
现在是时候提一下 pod 和容器之间的细微差别了;默认情况下如果 pod 中的进程退出 pod 也不会终止,相反它将会重启该进程。这类似于 docker run 时的 --restart=always
选项, 这是主要差别。在 docker 中,进程的每个调用的输出都是被连接起来的,但是对于 kubernetes,每个调用都是分开的。要查看以前在 kubernetes 中执行的输出,请执行以下操作:
kubectl logs --previous nginx-app-zibvs
10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
查看日志架构 获取更多信息。
docker stop and docker rm
如何停止和删除运行中的进程?查看 kubectl delete 。
使用 docker 命令:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a9ec34d98787 nginx "nginx -g 'daemon of" 22 hours ago Up 22 hours 0.0.0.0:80->80/tcp, 443/tcp nginx-app
a9ec34d98787
a9ec34d98787
使用 kubectl 命令:
kubectl get deployment nginx-app
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-app 1/1 1 1 2m
kubectl get po -l app = nginx-app
NAME READY STATUS RESTARTS AGE
nginx-app-2883164633-aklf7 1/1 Running 0 2m
kubectl delete deployment nginx-app
deployment "nginx-app" deleted
kubectl get po -l app = nginx-app
# Return nothing
说明:
请注意,我们不直接删除 pod。使用 kubectl 命令,我们要删除拥有该 pod 的 Deployment。如果我们直接删除 pod,Deployment 将会重新创建该 pod。
docker login
在 kubectl 中没有对 docker login
的直接模拟。如果您有兴趣在私有镜像仓库中使用 Kubernetes,请参阅使用私有镜像仓库 。
docker version
如何查看客户端和服务端的版本?查看 kubectl version 。
使用 docker 命令:
Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64
Server version: 1.7.0
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 0baf609
OS/Arch (server): linux/amd64
使用 kubectl 命令:
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
docker info
如何获取有关环境和配置的各种信息?查看 kubectl cluster-info 。
使用 docker 命令:
Containers: 40
Images: 168
Storage Driver: aufs
Root Dir: /usr/local/google/docker/aufs
Backing Filesystem: extfs
Dirs: 248
Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-53-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 12
Total Memory: 31.32 GiB
Name: k8s-is-fun.mtv.corp.google.com
ID: ADUV:GCYR:B3VJ:HMPO:LNPQ:KD5S:YKFQ:76VN:IANZ:7TFV:ZBF4:BYJO
WARNING: No swap limit support
使用 kubectl 命令:
Kubernetes master is running at https://108.59.85.141
KubeDNS is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/kube-dns/proxy
kubernetes-dashboard is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy
Grafana is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
Heapster is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
InfluxDB is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
11 - 组件工具
11.2 - kubelet
简介
kubelet 是在每个 Node 节点上运行的主要 “节点代理”。它可以使用以下之一向 apiserver 注册:
主机名(hostname);覆盖主机名的参数;某云驱动的特定逻辑。
kubelet 是基于 PodSpec 来工作的。每个 PodSpec 是一个描述 Pod 的 YAML 或 JSON 对象。
kubelet 接受通过各种机制(主要是通过 apiserver)提供的一组 PodSpec,并确保这些
PodSpec 中描述的容器处于运行状态且运行状况良好。
kubelet 不管理不是由 Kubernetes 创建的容器。
除了来自 apiserver 的 PodSpec 之外,还可以通过以下三种方式将容器清单(manifest)提供给 kubelet。
文件(File):利用命令行参数传递路径。kubelet 周期性地监视此路径下的文件是否有更新。
监视周期默认为 20s,且可通过参数进行配置。
HTTP 端点(HTTP endpoint):利用命令行参数指定 HTTP 端点。
此端点的监视周期默认为 20 秒,也可以使用参数进行配置。
HTTP 服务器(HTTP server):kubelet 还可以侦听 HTTP 并响应简单的 API
(目前没有完整规范)来提交新的清单。
kubelet [flags]
选项
--add-dir-header
设置为 true 表示将文件目录添加到日志消息的头部
--address ip 默认值:0.0.0.0
kubelet 用来提供服务的 IP 地址(设置为0.0.0.0
表示使用所有 IPv4 接口,
设置为 ::
表示使用所有 IPv6 接口)。已弃用:应在 --config
所给的
配置文件中进行设置。(进一步了解 )
--allowed-unsafe-sysctls strings
用逗号分隔的字符串序列设置允许使用的非安全的 sysctls 或 sysctl 模式(以 *
结尾) 。
使用此参数时风险自担。已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--alsologtostderr
设置为 true 表示将日志输出到文件的同时输出到 stderr
--anonymous-auth 默认值:true
设置为 true 表示 kubelet 服务器可以接受匿名请求。未被任何认证组件拒绝的请求将被视为匿名请求。
匿名请求的用户名为 system:anonymous
,用户组为 system:unauthenticated
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--authentication-token-webhook
使用 TokenReview
API 对持有者令牌进行身份认证。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--authentication-token-webhook-cache-ttl duration 默认值:2m0s
对 Webhook 令牌认证组件所返回的响应的缓存时间。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--authorization-mode string
kubelet 服务器的鉴权模式。可选值包括:AlwaysAllow
、Webhook
。Webhook
模式使用 SubjectAccessReview
API 鉴权。
当 --config
参数未被设置时,默认值为 AlwaysAllow
,当使用了
--config
时,默认值为 Webhook
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--authorization-webhook-cache-authorized-ttl duration 默认值:5m0s
对 Webhook 认证组件所返回的 “Authorized(已授权)” 应答的缓存时间。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--authorization-webhook-cache-unauthorized-ttl duration 默认值:30s
对 Webhook 认证组件所返回的 “Unauthorized(未授权)” 应答的缓存时间。
--config
时,默认值为 Webhook
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--azure-container-registry-config string
包含 Azure 容器镜像库配置信息的文件的路径。
--bootstrap-kubeconfig string
某 kubeconfig 文件的路径,该文件将用于获取 kubelet 的客户端证书。
如果 --kubeconfig
所指定的文件不存在,则使用引导所用 kubeconfig
从 API 服务器请求客户端证书。成功后,将引用生成的客户端证书和密钥的 kubeconfig
写入 --kubeconfig 所指定的路径。客户端证书和密钥文件将存储在 --cert-dir
所指的目录。
--cert-dir string 默认值:/var/lib/kubelet/pki
TLS 证书所在的目录。如果设置了 --tls-cert-file
和 --tls-private-key-file
,
则此标志将被忽略。
--cgroup-driver string 默认值:cgroupfs
kubelet 用来操作本机 cgroup 时使用的驱动程序。支持的选项包括 cgroupfs
和 systemd
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--cgroup-root string 默认值:""
可选的选项,为 Pod 设置根 cgroup。容器运行时会尽可能使用此配置。
默认值 ""
意味着将使用容器运行时的默认设置。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--cgroups-per-qos 默认值:true
启用创建 QoS cgroup 层次结构。此值为 true 时 kubelet 为 QoS 和 Pod 创建顶级的 cgroup。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--chaos-chance float
如果此值大于 0.0,则引入随机客户端错误和延迟。用于测试。
已启用:将在未来版本中移除。
--client-ca-file string
如果设置了此参数,则使用对应文件中机构之一检查请求中所携带的客户端证书。
若客户端证书通过身份认证,则其对应身份为其证书中所设置的 CommonName。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--cloud-config string
云驱动配置文件的路径。空字符串表示没有配置文件。
已弃用:将在 1.24 或更高版本中移除,以便于从 kubelet 中去除云驱动代码。
--cloud-provider string
云服务的提供者。设置为空字符串表示在没有云驱动的情况下运行。
如果设置了此标志,则云驱动负责确定节点的名称(参考云提供商文档以确定是否以及如何使用主机名)。
已弃用:将在 1.24 或更高版本中移除,以便于从 kubelet 中去除云驱动代码。
--cluster-dns strings
DNS 服务器的 IP 地址,以逗号分隔。此标志值用于 Pod 中设置了 “dnsPolicy=ClusterFirst
”
时为容器提供 DNS 服务。注意:列表中出现的所有 DNS 服务器必须包含相同的记录组,
否则集群中的名称解析可能无法正常工作。至于名称解析过程中会牵涉到哪些 DNS 服务器,
这一点无法保证。
--config
时,默认值为 Webhook
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--cluster-domain string
集群的域名。如果设置了此值,kubelet 除了将主机的搜索域配置到所有容器之外,还会为其
配置所搜这里指定的域名。
--config
时,默认值为 Webhook
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--cni-bin-dir string 默认值:/opt/cni/bin
<警告:alpha 特性> 此值为以逗号分隔的完整路径列表。
kubelet 将在所指定路径中搜索 CNI 插件的可执行文件。
仅当容器运行环境设置为 docker
时,此特定于 docker 的参数才有效。
--cni-cache-dir string 默认值:/var/lib/cni/cache
<警告:alpha 特性> 此值为一个目录的全路径名。CNI 将在其中缓存文件。
仅当容器运行环境设置为 docker
时,此特定于 docker 的参数才有效。
--cni-conf-dir string 默认值:/etc/cni/net.d
<警告:alpha 特性> 此值为某目录的全路径名。kubelet 将在其中搜索 CNI 配置文件。
仅当容器运行环境设置为 docker
时,此特定于 docker 的参数才有效。
--config string
kubelet 将从此标志所指的文件中加载其初始配置。此路径可以是绝对路径,也可以是相对路径。
相对路径按 kubelet 的当前工作目录起计。省略此参数时 kubelet 会使用内置的默认配置值。
命令行参数会覆盖此文件中的配置。
--container-log-max-files int32 默认值:5
设置容器的日志文件个数上限。此值必须不小于 2。
此标志只能与 --container-runtime=remote
标志一起使用。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--container-log-max-size string 默认值:10Mi
设置容器日志文件在轮换生成新文件时之前的最大值(例如,10Mi
)。
此标志只能与 --container-runtime=remote
标志一起使用。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--container-runtime string 默认值:docker
要使用的容器运行时。目前支持 docker、
remote
。
--container-runtime-endpoint string 默认值:unix:///var/run/dockershim.sock
[实验性特性] 远程运行时服务的端点。目前支持 Linux 系统上的 UNIX 套接字和
Windows 系统上的 npipe 和 TCP 端点。例如:
unix:///var/run/dockershim.sock
、
npipe:////./pipe/dockershim
。
--contention-profiling
当启用了性能分析时,启用锁竞争分析。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--cpu-cfs-quota 默认值:true
为设置了 CPU 限制的容器启用 CPU CFS 配额保障。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--cpu-cfs-quota-period duration 默认值:100ms
设置 CPU CFS 配额周期 cpu.cfs_period_us
。默认使用 Linux 内核所设置的默认值 。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--cpu-manager-policy string 默认值:none
要使用的 CPU 管理器策略。可选值包括:none
和 static
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--cpu-manager-reconcile-period duration 默认值:10s
<警告:alpha 特性> 设置 CPU 管理器的调和时间。例如:10s
或者 1m
。
如果未设置,默认使用节点状态更新频率。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--docker-endpoint string 默认值:unix:///var/run/docker.sock
使用这里的端点与 docker 端点通信。
仅当容器运行环境设置为 docker
时,此特定于 docker 的参数才有效。
--dynamic-config-dir string
kubelet 使用此目录来保存所下载的配置,跟踪配置运行状况。
如果目录不存在,则 kubelet 创建该目录。此路径可以是绝对路径,也可以是相对路径。
相对路径从 kubelet 的当前工作目录计算。
设置此参数将启用动态 kubelet 配置。必须启用 DynamicKubeletConfig
特性门控之后才能设置此标志。
(已弃用:DynamicKubeletConfig 功能在 1.22 中已弃用,不会移至 GA。
计划在 1.24 或更高版本中从 Kubernetes 中移除。
请使用其他方式来更新 kubelet 配置。)
--enable-controller-attach-detach 默认值:true
启用 Attach/Detach 控制器来挂接和摘除调度到该节点的卷,同时禁用 kubelet 执行挂接和摘除操作。
--enable-debugging-handlers 默认值:true
启用服务器上用于日志收集和在本地运行容器和命令的端点。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--enable-server
启用 kubelet 服务器。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--enforce-node-allocatable strings 默认值:pods
用逗号分隔的列表,包含由 kubelet 强制执行的节点可分配资源级别。
可选配置为:none
、pods
、system-reserved
和 kube-reserved
。
在设置 system-reserved
和 kube-reserved
这两个值时,同时要求设置
--system-reserved-cgroup
和 --kube-reserved-cgroup
这两个参数。
如果设置为 none
,则不需要设置其他参数。
参考相关文档 。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--event-burst int32 默认值:10
事件记录的个数的突发峰值上限,在遵从 --event-qps
阈值约束的前提下
临时允许事件记录达到此数目。仅在 --event-qps
大于 0 时使用。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--event-qps int32 默认值:5
设置大于 0 的值表示限制每秒可生成的事件数量。设置为 0 表示不限制。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--eviction-hard string 默认值:imagefs.available<15%,memory.available<100Mi,nodefs.available<10%
触发 Pod 驱逐操作的一组硬性门限(例如:memory.available<1Gi
(内存可用值小于 1 G))设置。在 Linux 节点上,默认值还包括
nodefs.inodesFree<5%
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--eviction-max-pod-grace-period int32
响应满足软性驱逐阈值(Soft Eviction Threshold)而终止 Pod 时使用的最长宽限期(以秒为单位)。
如果设置为负数,则遵循 Pod 的指定值。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--eviction-minimum-reclaim mapStringString
当某资源压力过大时,kubelet 将执行 Pod 驱逐操作。
此参数设置软性驱逐操作需要回收的资源的最小数量(例如:imagefs.available=2Gi
)。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--eviction-pressure-transition-period duration 默认值:5m0s
kubelet 在驱逐压力状况解除之前的最长等待时间。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--eviction-soft mapStringString
设置一组驱逐阈值(例如:memory.available<1.5Gi
)。
如果在相应的宽限期内达到该阈值,则会触发 Pod 驱逐操作。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--eviction-soft-grace-period mapStringString
设置一组驱逐宽限期(例如,memory.available=1m30s
),对应于触发软性 Pod
驱逐操作之前软性驱逐阈值所需持续的时间长短。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--exit-on-lock-contention
设置为 true 表示当发生锁文件竞争时 kubelet 可以退出。
--experimental-allocatable-ignore-eviction 默认值:false
设置为 true
表示在计算节点可分配资源数量时忽略硬性逐出阈值设置。
参考
相关文档 。
已启用:将在 1.24 或更高版本中移除。
--experimental-bootstrap-kubeconfig string
已弃用:应使用 --bootstrap-kubeconfig
标志
--experimental-check-node-capabilities-before-mount
[实验性特性] 设置为 true
表示 kubelet 在进行挂载卷操作之前要
在本节点上检查所需的组件(如可执行文件等)是否存在。
已弃用:将在 1.24 或更高版本中移除,以便使用 CSI。
--experimental-kernel-memcg-notification
设置为 true 表示 kubelet 将会集成内核的 memcg 通知机制而不是使用轮询机制来
判断是否达到了内存驱逐阈值。
此标志将在 1.24 或更高版本移除。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--experimental-log-sanitization
[试验性功能] 启用此标志之后,kubelet 会避免将标记为敏感的字段(密码、密钥、令牌等)
写入日志中。运行时的日志清理可能会带来相当的计算开销,因此不应该在
产品环境中启用。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--experimental-mounter-path string 默认值:mount
[实验性特性] 卷挂载器(mounter)的可执行文件的路径。设置为空表示使用默认挂载器 mount
。
已弃用:将在 1.24 或更高版本移除以支持 CSI。
--fail-swap-on 默认值:true
设置为 true 表示如果主机启用了交换分区,kubelet 将直接失败。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--feature-gates mapStringBool
用于 alpha 实验性特性的特性开关组,每个开关以 key=value 形式表示。当前可用开关包括:
APIListChunking=true|false (BETA - 默认值为 true)
APIPriorityAndFairness=true|false (BETA - 默认值为 true)
APIResponseCompression=true|false (BETA - 默认值为 true)
APIServerIdentity=true|false (ALPHA - 默认值为 false)
AllAlpha=true|false (ALPHA - 默认值为 false)
AllBeta=true|false (BETA - 默认值为 false)
AllowInsecureBackendProxy=true|false (BETA - 默认值为 true)
AnyVolumeDataSource=true|false (ALPHA - 默认值为 false)
AppArmor=true|false (BETA - 默认值为 true)
BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值为 false)
BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值为 false)
CPUManager=true|false (BETA - 默认值为 true)
CSIInlineVolume=true|false (BETA - 默认值为 true)
CSIMigration=true|false (BETA - 默认值为 true)
CSIMigrationAWS=true|false (BETA - 默认值为 false)
CSIMigrationAWSComplete=true|false (ALPHA - 默认值为 false)
CSIMigrationAzureDisk=true|false (BETA - 默认值为 false)
CSIMigrationAzureDiskComplete=true|false (ALPHA - 默认值为 false)
CSIMigrationAzureFile=true|false (ALPHA - 默认值为 false)
CSIMigrationAzureFileComplete=true|false (ALPHA - 默认值为 false)
CSIMigrationGCE=true|false (BETA - 默认值为 false)
CSIMigrationGCEComplete=true|false (ALPHA - 默认值为 false)
CSIMigrationOpenStack=true|false (BETA - 默认值为 false)
CSIMigrationOpenStackComplete=true|false (ALPHA - 默认值为 false)
CSIMigrationvSphere=true|false (BETA - 默认值为 false)
CSIMigrationvSphereComplete=true|false (BETA - 默认值为 false)
CSIServiceAccountToken=true|false (ALPHA - 默认值为 false)
CSIStorageCapacity=true|false (ALPHA - 默认值为 false)
CSIVolumeFSGroupPolicy=true|false (BETA - 默认值为 true)
ConfigurableFSGroupPolicy=true|false (BETA - 默认值为 true)
CronJobControllerV2=true|false (ALPHA - 默认值为 false)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值为 false)
DefaultPodTopologySpread=true|false (BETA - 默认值为 true)
DevicePlugins=true|false (BETA - 默认值为 true)
DisableAcceleratorUsageMetrics=true|false (BETA - 默认值为 true)
DownwardAPIHugePages=true|false (ALPHA - 默认值为 false)
DynamicKubeletConfig=true|false (BETA - 默认值为 true)
EfficientWatchResumption=true|false (ALPHA - 默认值为 false)
EndpointSlice=true|false (BETA - 默认值为 true)
EndpointSliceNodeName=true|false (ALPHA - 默认值为 false)
EndpointSliceProxying=true|false (BETA - 默认值为 true)
EndpointSliceTerminatingCondition=true|false (ALPHA - 默认值为 false)
EphemeralContainers=true|false (ALPHA - 默认值为 false)
ExpandCSIVolumes=true|false (BETA - 默认值为 true)
ExpandInUsePersistentVolumes=true|false (BETA - 默认值为 true)
ExpandPersistentVolumes=true|false (BETA - 默认值为 true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值为 false)
GenericEphemeralVolume=true|false (ALPHA - 默认值为 false)
GracefulNodeShutdown=true|false (ALPHA - 默认值为 false)
HPAContainerMetrics=true|false (ALPHA - 默认值为 false)
HPAScaleToZero=true|false (ALPHA - 默认值为 false)
HugePageStorageMediumSize=true|false (BETA - 默认值为 true)
IPv6DualStack=true|false (ALPHA - 默认值为 false)
ImmutableEphemeralVolumes=true|false (BETA - 默认值为 true)
KubeletCredentialProviders=true|false (ALPHA - 默认值为 false)
KubeletPodResources=true|false (BETA - 默认值为 true)
LegacyNodeRoleBehavior=true|false (BETA - 默认值为 true)
LocalStorageCapacityIsolation=true|false (BETA - 默认值为 true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值为 false)
MixedProtocolLBService=true|false (ALPHA - 默认值为 false)
NodeDisruptionExclusion=true|false (BETA - 默认值为 true)
NonPreemptingPriority=true|false (BETA - 默认值为 true)
PodDisruptionBudget=true|false (BETA - 默认值为 true)
PodOverhead=true|false (BETA - 默认值为 true)
ProcMountType=true|false (ALPHA - 默认值为 false)
QOSReserved=true|false (ALPHA - 默认值为 false)
RemainingItemCount=true|false (BETA - 默认值为 true)
RemoveSelfLink=true|false (BETA - 默认值为 true)
RootCAConfigMap=true|false (BETA - 默认值为 true)
RotateKubeletServerCertificate=true|false (BETA - 默认值为 true)
RunAsGroup=true|false (BETA - 默认值为 true)
SeccompDefault=true|false (ALPHA - 默认值为 false)
ServiceInternalTrafficPolicy=true|false (BETA - 默认值为 true)
ServiceLBNodePortControl=true|false (BETA - 默认值为 true)
ServiceLoadBalancerClass=true|false (BETA - 默认值为 true)
SizeMemoryBackedVolumes=true|false (BETA - 默认值为 true)
StatefulSetAutoDeletePVC=true|false (ALPHA - 默认值为 false)
StatefulSetMinReadySeconds=true|false (BETA - 默认值为 true)
StorageVersionAPI=true|false (ALPHA - 默认值为 false)
StorageVersionHash=true|false (BETA - 默认值为 true)
SuspendJob=true|false (BETA - 默认值为 true)
TopologyAwareHints=true|false (BETA - 默认值为 true)
TopologyManager=true|false (BETA - 默认值为 true)
VolumeCapacityPriority=true|false (ALPHA - 默认值为 false)
WinDSR=true|false (ALPHA - 默认值为 false)
WinOverlay=true|false (BETA - 默认值为 true)
WindowsHostProcessContainers=true|false (BETA - 默认值为 true)
csiMigrationRBD=true|false (ALPHA - 默认值为 false)
已弃用: 应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--file-check-frequency duration 默认值:20s
检查配置文件中新数据的时间间隔。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--hairpin-mode string 默认值:promiscuous-bridge
设置 kubelet 执行发夹模式(hairpin)网络地址转译的方式。
该模式允许后端端点对其自身服务的访问能够再次经由负载均衡转发回自身。
可选项包括 promiscuous-bridge
、hairpin-veth
和 none
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--healthz-bind-address ip 默认值:127.0.0.1
用于运行 healthz 服务器的 IP 地址(设置为 0.0.0.0
表示使用所有 IPv4 接口,
设置为 ::
表示使用所有 IPv6 接口。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--healthz-port int32 默认值:10248
本地 healthz 端点使用的端口(设置为 0 表示禁用)。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
-h, --help
kubelet 操作的帮助命令
--hostname-override string
如果为非空,将使用此字符串而不是实际的主机名作为节点标识。如果设置了
--cloud-provider
,则云驱动将确定节点的名称
(请查阅云服务商文档以确定是否以及如何使用主机名)。
--housekeeping-interval duration 默认值:10s
清理容器操作的时间间隔。
--http-check-frequency duration 默认值:20s
HTTP 服务以获取新数据的时间间隔。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--image-credential-provider-bin-dir string
指向凭据提供组件可执行文件所在目录的路径。
--image-credential-provider-config string
指向凭据提供插件配置文件所在目录的路径。
--image-gc-high-threshold int32 默认值:85
镜像垃圾回收上限。磁盘使用空间达到该百分比时,镜像垃圾回收将持续工作。
值必须在 [0,100] 范围内。要禁用镜像垃圾回收,请设置为 100。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--image-gc-low-threshold int32 默认值:80
镜像垃圾回收下限。磁盘使用空间在达到该百分比之前,镜像垃圾回收操作不会运行。
值必须在 [0,100] 范围内,并且不得大于 --image-gc-high-threshold
的值。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--image-pull-progress-deadline duration 默认值:1m0s
如果在该参数值所设置的期限之前没有拉取镜像的进展,镜像拉取操作将被取消。
仅当容器运行环境设置为 docker
时,此特定于 docker 的参数才有效。
--image-service-endpoint string
[实验性特性] 远程镜像服务的端点。若未设定则默认情况下使用 --container-runtime-endpoint
的值。目前支持的类型包括在 Linux 系统上的 UNIX 套接字端点和 Windows 系统上的 npipe 和 TCP 端点。
例如:unix:///var/run/dockershim.sock
、npipe:////./pipe/dockershim
。
--iptables-drop-bit int32 默认值:15
标记数据包将被丢弃的 fwmark 位设置。必须在 [0,31] 范围内。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--iptables-masquerade-bit int32 默认值:14
标记数据包将进行 SNAT 的 fwmark 空间位设置。必须在 [0,31] 范围内。
请将此参数与 kube-proxy
中的相应参数匹配。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--keep-terminated-pod-volumes
设置为 true 表示 Pod 终止后仍然保留之前挂载过的卷,常用于调试与卷有关的问题。
已弃用:将未来版本中移除。
--kernel-memcg-notification
若启用,则 kubelet 将与内核中的 memcg 通知机制集成,不再使用轮询的方式来判定
是否 Pod 达到内存驱逐阈值。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--kube-api-burst int32 默认值:10
每秒发送到 apiserver 的突发请求数量上限。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--kube-api-content-type string 默认值:application/vnd.kubernetes.protobuf
发送到 apiserver 的请求的内容类型。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--kube-api-qps int32 默认值:5
与 apiserver 通信的每秒查询个数(QPS)。
此值必须 >= 0。如果为 0, 则使用默认 QPS(5)。
不包含事件和节点心跳 api,它们的速率限制是由一组不同的标志所控制。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--kube-reserved mapStringString 默认值:<None>
kubernetes 系统预留的资源配置,以一组 资源名称=资源数量
格式表示。
(例如:cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100'
)。
当前支持 cpu
、memory
和用于根文件系统的 ephemeral-storage
。
请参阅相关文档 获取更多信息。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--kube-reserved-cgroup string 默认值:""
给出某个顶层 cgroup 绝对名称,该 cgroup 用于管理通过标志 --kube-reserved
为 kubernetes 组件所预留的计算资源。例如:"/kube-reserved"
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--kubeconfig string
kubeconfig 配置文件的路径,指定如何连接到 API 服务器。
提供 --kubeconfig
将启用 API 服务器模式,而省略 --kubeconfig
将启用独立模式。
--kubelet-cgroups string
用于创建和运行 kubelet 的 cgroup 的绝对名称。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--lock-file string
<警告:alpha 特性> kubelet 使用的锁文件的路径。
--log-backtrace-at traceLocation 默认值::0
形式为 <file>:<N>
。
当日志逻辑执行到命中 <file> 的第 <N> 行时,转储调用堆栈。
(已弃用:将在未来的版本中删除,进一步了解 )
--log-dir string
如果此值为非空,则在所指定的目录中写入日志文件。
(已弃用:将在未来的版本中删除,进一步了解 )
--log-file string
如果此值非空,使用所给字符串作为日志文件名。
--log-file-max-size uint 默认值:1800
设置日志文件的最大值。单位为兆字节(M)。如果值为 0,则表示文件大小无限制。
(已弃用:将在未来的版本中删除,进一步了解 )
--log-flush-frequency duration 默认值:5s
两次日志刷新之间的最大秒数(默认值为 5s)。
--log-json-info-buffer-size string 默认值:'0'
[实验性特性]在具有拆分输出流的 JSON 格式中,可以将信息消息缓冲一段时间以提高性能。
零字节的默认值禁用缓冲。大小可以指定为字节数(512)、1000 的倍数(1K)、1024 的倍数(2Ki) 或这些(3M、4G、5Mi、6Gi)的幂。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--log-json-split-stream
[实验性特性]以 JSON 格式,将错误消息写入 stderr,将 info 消息写入 stdout。
默认是将单个流写入标准输出。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--logging-format string 默认值:"text"
设置日志文件格式。可以设置的格式有:"text"
、"json"
。
非默认的格式不会使用以下标志的配置:--add-dir-header
, --alsologtostderr
,
--log-backtrace-at
, --log-dir
, --log-file
,
--log-file-max-size
, --logtostderr
, --skip-headers
,
--skip-log-headers
, --stderrthreshold
, --log-flush-frequency
。
非默认选项的其它值都应视为 Alpha 特性,将来出现更改时不会额外警告。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--logtostderr 默认值:true
日志输出到 stderr 而不是文件。
(已弃用:将会在未来的版本删除,
进一步了解 )
--make-iptables-util-chains 默认值:true
设置为 true 表示 kubelet 将确保 iptables
规则在主机上存在。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--manifest-url string
用于访问要运行的其他 Pod 规范的 URL。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--manifest-url-header string
取值为由 HTTP 头部组成的逗号分隔列表,在访问 --manifest-url
所给出的 URL 时使用。
名称相同的多个头部将按所列的顺序添加。该参数可以多次使用。例如:
--manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful'
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--master-service-namespace string 默认值:default
kubelet 向 Pod 注入 Kubernetes 主控服务信息时使用的命名空间。
已弃用:此标志将在未来的版本中删除。
--max-open-files int 默认值:1000000
kubelet 进程可以打开的最大文件数量。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--max-pods int32 默认值:110
此 kubelet 能运行的 Pod 最大数量。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--maximum-dead-containers int32 默认值:-1
设置全局可保留的已停止容器实例个数上限。
每个实例会占用一些磁盘空间。要禁用,请设置为负数。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--maximum-dead-containers-per-container int32 默认值:1
每个已停止容器可以保留的的最大实例数量。每个容器占用一些磁盘空间。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--memory-manager-policy string 默认值:None
内存管理器策略使用。可选值:'None'
, 'Static'
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--minimum-container-ttl-duration duration
已结束的容器在被垃圾回收清理之前的最少存活时间。
例如:300ms
、10s
或者 2h45m
。
已弃用:请改用 --eviction-hard
或者 --eviction-soft
。
此标志将在未来的版本中删除。
--minimum-image-ttl-duration duration 默认值:2m0s
不再使用的镜像在被垃圾回收清理之前的最少存活时间。
例如:300ms
、10s
或者 2h45m
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--network-plugin string
<警告:alpha 特性> 设置 kubelet/Pod 生命周期中各种事件调用的网络插件的名称。
仅当容器运行环境设置为 docker
时,此特定于 docker 的参数才有效。
--network-plugin-mtu int32
<警告:alpha 特性> 传递给网络插件的 MTU 值,将覆盖默认值。
设置为 0 则使用默认的 MTU 1460。仅当容器运行环境设置为 docker
时,
此特定于 docker 的参数才有效。
(已弃用:将会随着 dockershim 一起删除。)
--node-ip string
节点的 IP 地址(或逗号分隔的双栈 IP 地址)。
如果未设置,kubelet 将使用节点的默认 IPv4 地址(如果有)或默认 IPv6 地址(如果它没有 IPv4 地址)。
你可以传值 '::'
使其偏向于默认的 IPv6 地址而不是默认的 IPv4 地址。
--node-labels mapStringString
<警告:alpha 特性> kubelet 在集群中注册本节点时设置的标签。标签以
key=value
的格式表示,多个标签以逗号分隔。名字空间 kubernetes.io
中的标签必须以 kubelet.kubernetes.io
或 node.kubernetes.io
为前缀,
或者在以下明确允许范围内:
beta.kubernetes.io/arch
, beta.kubernetes.io/instance-type
,
beta.kubernetes.io/os
, failure-domain.beta.kubernetes.io/region
,
failure-domain.beta.kubernetes.io/zone
, kubernetes.io/arch
,
kubernetes.io/hostname
, kubernetes.io/os
,
node.kubernetes.io/instance-type
, topology.kubernetes.io/region
,
topology.kubernetes.io/zone
。
--node-status-max-images int32 默认值:50
在 node.status.images
中可以报告的最大镜像数量。如果指定为 -1,则不设上限。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--node-status-update-frequency duration 默认值:10s
指定 kubelet 向主控节点汇报节点状态的时间间隔。注意:更改此常量时请务必谨慎,
它必须与节点控制器中的 nodeMonitorGracePeriod
一起使用。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--non-masquerade-cidr string 默认值:10.0.0.0/8
kubelet 向该 IP 段之外的 IP 地址发送的流量将使用 IP 伪装技术。
设置为 0.0.0.0/0
则不使用伪装。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--one-output
如果设置此标志为 true
,则仅将日志写入其原来的严重性级别中,
而不是同时将其写入更低严重性级别中。
已弃用:将在未来的版本中删除,
(进一步了解 )
--oom-score-adj int32 默认值:-999
kubelet 进程的 oom-score-adj 参数值。有效范围为 [-1000,1000]
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--pod-cidr string
用于给 Pod 分配 IP 地址的 CIDR 地址池,仅在独立运行模式下使用。
在集群模式下,CIDR 设置是从主服务器获取的。对于 IPv6,分配的 IP 的最大数量为 65536。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--pod-infra-container-image string 默认值:k8s.gcr.io/pause:3.2
所指定的镜像不会被镜像垃圾收集器删除。
当容器运行环境设置为 docker
时,各个 Pod 中的所有容器都会
使用此镜像中的网络和 IPC 名字空间。
其他 CRI 实现有自己的配置来设置此镜像。
--pod-manifest-path string
设置包含要运行的静态 Pod 的文件的路径,或单个静态 Pod 文件的路径。以点(.
)
开头的文件将被忽略。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--pod-max-pids int 默认值:-1
设置每个 Pod 中的最大进程数目。如果为 -1,则 kubelet 使用节点可分配的 PID 容量作为默认值。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--pods-per-core int32
kubelet 在每个处理器核上可运行的 Pod 数量。此 kubelet 上的 Pod 总数不能超过
--max-pods
标志值。因此,如果此计算结果导致在 kubelet
上允许更多数量的 Pod,则使用 --max-pods
值。值为 0 表示不作限制。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--port int32 默认值:10250
kubelet 服务监听的本机端口号。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--protect-kernel-defaults
设置 kubelet 的默认内核调整行为。如果已设置该参数,当任何内核可调参数与
kubelet 默认值不同时,kubelet 都会出错。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--provider-id string
设置主机数据库(即,云驱动)中用来标识节点的唯一标识。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--qos-reserved mapStringString
<警告:alpha 特性> 设置在指定的 QoS 级别预留的 Pod 资源请求,以一组
"资源名称=百分比"
的形式进行设置,例如 memory=50%
。
当前仅支持内存(memory)。要求启用 QOSReserved
特性门控。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--read-only-port int32 默认值:10255
kubelet 可以在没有身份验证/鉴权的情况下提供只读服务的端口(设置为 0 表示禁用)。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--really-crash-for-testing
设置为 true 表示发生失效时立即崩溃。仅用于测试。
已弃用:将在未来版本中移除。
--register-node 默认值:true
向 API 服务器注册节点,如果未提供 --kubeconfig
,此标志无关紧要,
因为 Kubelet 没有 API 服务器可注册。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--register-schedulable 默认值:true
注册本节点为可调度的节点。当 --register-node
标志为 false 时此设置无效。
已弃用:此参数将在未来的版本中删除。
--register-with-taints mapStringString
设置本节点的污点标记,格式为 <key>=<value>:<effect>
,
以逗号分隔。当 --register-node
为 false 时此标志无效。
已弃用:将在未来版本中移除。
--registry-burst int32 默认值:10
设置突发性镜像拉取的个数上限,在不超过 --registration-qps
设置值的前提下
暂时允许此参数所给的镜像拉取个数。仅在 --registry-qps
大于 0 时使用。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--registry-qps int32 默认值:5
如此值大于 0,可用来限制镜像仓库的 QPS 上限。设置为 0,表示不受限制。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--reserved-cpus string
用逗号分隔的一组 CPU 或 CPU 范围列表,给出为系统和 Kubernetes 保留使用的 CPU。
此列表所给出的设置优先于通过 --system-reserved
和
--kube-reskube-reserved
所保留的 CPU 个数配置。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--reserved-memory string
以逗号分隔的 NUMA 节点内存预留列表。(例如 --reserved-memory 0:memory=1Gi,hugepages-1M=2Gi --reserved-memory 1:memory=2Gi
)。
每种内存类型的总和应该等于--kube-reserved
、--system-reserved
和--eviction-threshold之和 代码>。
了解更多详细信息。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--resolv-conf string 默认值:/etc/resolv.conf
名字解析服务的配置文件名,用作容器 DNS 解析配置的基础。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--root-dir string 默认值:/var/lib/kubelet
设置用于管理 kubelet 文件的根目录(例如挂载卷的相关文件等)。
--rotate-certificates
<警告:Beta 特性> 设置当客户端证书即将过期时 kubelet 自动从
kube-apiserver
请求新的证书进行轮换。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--rotate-server-certificates
当 kubelet 的服务证书即将过期时自动从 kube-apiserver 请求新的证书进行轮换。
要求启用 RotateKubeletServerCertificate
特性门控,以及对提交的
CertificateSigningRequest
对象进行批复(Approve)操作。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--runonce
设置为 true 表示从本地清单或远程 URL 创建完 Pod 后立即退出 kubelet 进程。
与 --enable-server
标志互斥。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--runtime-cgroups string
设置用于创建和运行容器运行时的 cgroup 的绝对名称。
--runtime-request-timeout duration 默认值:2m0s
设置除了长时间运行的请求(包括 pull
、logs
、exec
和 attach
等操作)之外的其他运行时请求的超时时间。
到达超时时间时,请求会被取消,抛出一个错误并会等待重试。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--seccomp-profile-root string 默认值:/var/lib/kubelet/seccomp
<警告:alpha 特性> seccomp 配置文件目录。
已弃用:将在 1.23 或更高版本中移除,以使用 <root-dir>/seccomp
目录。
--serialize-image-pulls 默认值:true
逐一拉取镜像。建议 *不要* 在 docker 守护进程版本低于 1.9 或启用了 Aufs 存储后端的节点上
更改默认值。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--skip-headers
设置为 true 时在日志消息中去掉标头前缀。
(已弃用:将在未来的版本中删除,进一步了解 )
--skip-log-headers
设置为 true,打开日志文件时去掉标头。
(已弃用:将在未来的版本中删除,进一步了解 )
--stderrthreshold int 默认值:2
设置严重程度达到或超过此阈值的日志输出到标准错误输出。
(已弃用:将在未来的版本中删除,进一步了解 )
--streaming-connection-idle-timeout duration 默认值:4h0m0s
设置流连接在自动关闭之前可以空闲的最长时间。0 表示没有超时限制。
例如:5m
。
注意:与 kubelet 服务器的所有连接最长持续时间为 4 小时。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--sync-frequency duration 默认值:1m0s
在运行中的容器与其配置之间执行同步操作的最长时间间隔。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--system-cgroups /
此标志值为一个 cgroup 的绝对名称,用于所有尚未放置在根目录下某 cgroup 内的非内核进程。
空值表示不指定 cgroup。回滚该参数需要重启机器。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--system-reserved mapStringString 默认值:无
系统预留的资源配置,以一组 资源名称=资源数量
的格式表示,
(例如:cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100'
)。
目前仅支持 cpu
和 memory
的设置。
更多细节可参考
相关文档 。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--system-reserved-cgroup string 默认值:""
此标志给出一个顶层 cgroup 绝对名称,该 cgroup 用于管理非 kubernetes 组件,
这些组件的计算资源通过 --system-reserved
标志进行预留。
例如 "/system-reserved"
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--tls-cert-file string
包含 x509 证书的文件路径,用于 HTTPS 认证。
如果有中间证书,则中间证书要串接在在服务器证书之后。
如果未提供 --tls-cert-file
和 --tls-private-key-file
,
kubelet 会为公开地址生成自签名证书和密钥,并将其保存到通过
--cert-dir
指定的目录中。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--tls-cipher-suites string
服务器端加密算法列表,以逗号分隔。如果不设置,则使用 Go 语言加密包的默认算法列表。
首选算法:
TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384
不安全算法:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--tls-min-version string
设置支持的最小 TLS 版本号,可选的版本号包括:VersionTLS10
、
VersionTLS11
、VersionTLS12
和 VersionTLS13
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--tls-private-key-file string
包含与 --tls-cert-file
对应的 x509 私钥文件路径。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--topology-manager-policy string 默认值:none
设置拓扑管理策略(Topology Manager policy)。可选值包括:none
、
best-effort
、restricted
和 single-numa-node
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--topology-manager-scope string 默认值:container
拓扑提示信息使用范围。拓扑管理器从提示提供者(Hints Providers)处收集提示信息,
并将其应用到所定义的范围以确保 Pod 准入。
可选值包括:container
(默认)、pod
。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
-v, --v Level
设置 kubelet 日志级别详细程度的数值。
--version version[=true]
打印 kubelet 版本信息并退出。
--vmodule moduleSpec
以逗号分隔的 pattern=N
设置列表,用于文件过滤的日志记录
--volume-plugin-dir string 默认值:/usr/libexec/kubernetes/kubelet-plugins/volume/exec/
用来搜索第三方存储卷插件的目录。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
--volume-stats-agg-period duration 默认值:1m0s
指定 kubelet 计算和缓存所有 Pod 和卷的磁盘用量总值的时间间隔。要禁用磁盘用量计算,
请设置为 0。
已弃用:应在 --config
所给的配置文件中进行设置。
(进一步了解 )
11.3 - kube-apiserver
简介
Kubernetes API 服务器验证并配置 API 对象的数据,
这些对象包括 pods、services、replicationcontrollers 等。
API 服务器为 REST 操作提供服务,并为集群的共享状态提供前端,
所有其他组件都通过该前端进行交互。
kube-apiserver [flags]
选项
--add-dir-header
如果为 true,则将文件目录添加到日志消息的标题中
--admission-control-config-file string
包含准入控制配置的文件。
--advertise-address string
向集群成员通知 apiserver 消息的 IP 地址。
这个地址必须能够被集群中其他成员访问。
如果 IP 地址为空,将会使用 --bind-address,
如果未指定 --bind-address,将会使用主机的默认接口地址。
--allow-metric-labels stringToString 默认值:[]
允许使用的指标标签到指标值的映射列表。键的格式为 <MetricName>,<LabelName>.
值的格式为 <allowed_value>,<allowed_value>...。
例如:metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'
。
--allow-privileged
如果为 true, 将允许特权容器。[默认值=false]
--alsologtostderr
在向文件输出日志的同时,也将日志写到标准输出。
--anonymous-auth 默认值:true
启用到 API 服务器的安全端口的匿名请求。
未被其他认证方法拒绝的请求被当做匿名请求。
匿名请求的用户名为 system:anonymous
,
用户组名为 system:unauthenticated。
--api-audiences strings
API 的标识符。
服务帐户令牌验证者将验证针对 API 使用的令牌是否已绑定到这些受众中的至少一个。
如果配置了 --service-account-issuer
标志,但未配置此标志,
则此字段默认为包含发布者 URL 的单个元素列表。
--apiserver-count int 默认值:1
集群中运行的 API 服务器数量,必须为正数。
(在启用 --endpoint-reconciler-type=master-count 时使用。)
--audit-log-batch-buffer-size int 默认值:10000
批处理和写入之前用于存储事件的缓冲区大小。
仅在批处理模式下使用。
--audit-log-batch-max-size int 默认值:1
每个批次的最大大小。仅在批处理模式下使用。
--audit-log-batch-max-wait duration
强制写入尚未达到最大大小的批次之前要等待的时间。
仅在批处理模式下使用。
--audit-log-batch-throttle-burst int
如果之前未使用 ThrottleQPS,则为同时发送的最大请求数。
仅在批处理模式下使用。
--audit-log-batch-throttle-enable
是否启用了批量限制。仅在批处理模式下使用。
--audit-log-batch-throttle-qps float
每秒的最大平均批次数。仅在批处理模式下使用。
--audit-log-compress
若设置了此标志,则被轮换的日志文件会使用 gzip 压缩。
--audit-log-format string 默认值:"json"
所保存的审计格式。
"legacy" 表示每行一个事件的文本格式。"json" 表示结构化的 JSON 格式。
已知格式为 legacy,json。
--audit-log-maxage int
根据文件名中编码的时间戳保留旧审计日志文件的最大天数。
--audit-log-maxbackup int
要保留的旧的审计日志文件个数上限。
--audit-log-maxsize int
轮换之前,审计日志文件的最大大小(以兆字节为单位)。
--audit-log-mode string 默认值:"blocking"
用来发送审计事件的策略。
阻塞(blocking)表示发送事件应阻止服务器响应。
批处理(batch)会导致后端异步缓冲和写入事件。
已知的模式是批处理(batch),阻塞(blocking),严格阻塞(blocking-strict)。
--audit-log-path string
如果设置,则所有到达 API 服务器的请求都将记录到该文件中。
"-" 表示标准输出。
--audit-log-truncate-enabled
是否启用事件和批次截断。
--audit-log-truncate-max-batch-size int 默认值:10485760
发送到下层后端的每批次的最大数据量。
实际的序列化大小可能会增加数百个字节。
如果一个批次超出此限制,则将其分成几个较小的批次。
--audit-log-truncate-max-event-size int 默认值:102400
发送到下层后端的每批次的最大数据量。
如果事件的大小大于此数字,则将删除第一个请求和响应;
如果这样做没有减小足够大的程度,则将丢弃事件。
--audit-log-version string 默认值:"audit.k8s.io/v1"
用于对写入日志的审计事件执行序列化的 API 组和版本。
--audit-policy-file string
定义审计策略配置的文件的路径。
--audit-webhook-batch-buffer-size int 默认值:10000
划分批次和写入之前用于存储事件的缓冲区大小。
仅在批处理模式下使用。
--audit-webhook-batch-max-size int 默认值:400
批次的最大大小。
仅在批处理模式下使用。
--audit-webhook-batch-max-wait duration 默认值:30s
强制写入尚未达到最大大小的批处理之前要等待的时间。
仅在批处理模式下使用。
--audit-webhook-batch-throttle-burst int 默认值:15
如果之前未使用 ThrottleQPS,同时发送的最大请求数。
仅在批处理模式下使用。
--audit-webhook-batch-throttle-enable 默认值:true
是否启用了批量限制。仅在批处理模式下使用。
--audit-webhook-batch-throttle-qps float32 默认值:10
每秒的最大平均批次数。仅在批处理模式下使用。
--audit-webhook-config-file string
定义审计 webhook 配置的 kubeconfig 格式文件的路径。
--audit-webhook-initial-backoff duration 默认值:10s
重试第一个失败的请求之前要等待的时间。
--audit-webhook-mode string 默认值:"batch"
发送审计事件的策略。
阻止(Blocking)表示发送事件应阻止服务器响应。
批处理(Batch)导致后端异步缓冲和写入事件。
已知的模式是批处理(batch),阻塞(blocking),严格阻塞(blocking-strict)。
--audit-webhook-truncate-enabled
是否启用事件和批处理截断。
--audit-webhook-truncate-max-batch-size int 默认值:10485760
发送到下层后端的批次的最大数据量。
实际的序列化大小可能会增加数百个字节。
如果一个批次超出此限制,则将其分成几个较小的批次。
--audit-webhook-truncate-max-event-size int 默认值:102400
发送到下层后端的批次的最大数据量。
如果事件的大小大于此数字,则将删除第一个请求和响应;
如果事件和事件的大小没有减小到一定幅度,则将丢弃事件。
--audit-webhook-version string 默认值:"audit.k8s.io/v1"
用于序列化写入 Webhook 的审计事件的 API 组和版本。
--authentication-token-webhook-cache-ttl duration 2m0s
对来自 Webhook 令牌身份验证器的响应的缓存时间。
--authentication-token-webhook-config-file string
包含 Webhook 配置的 kubeconfig 格式文件,用于进行令牌认证。
API 服务器将查询远程服务,以对持有者令牌进行身份验证。
--authentication-token-webhook-version string 默认值:"v1beta1"
与 Webhook 之间交换 authentication.k8s.io TokenReview 时使用的 API 版本。
--authorization-mode stringSlice 默认值:"AlwaysAllow"
在安全端口上进行鉴权的插件的顺序列表。
逗号分隔的列表:AlwaysAllow、AlwaysDeny、ABAC、Webhook、RBAC、Node。
--authorization-policy-file string
包含鉴权策略的文件,其内容为分行 JSON 格式,
在安全端口上与 --authorization-mode=ABAC 一起使用。
--authorization-webhook-cache-authorized-ttl duration 默认值:5m0s
对来自 Webhook 鉴权组件的 “授权(authorized)” 响应的缓存时间。
--authorization-webhook-cache-unauthorized-ttl duration 默认值:30s
对来自 Webhook 鉴权模块的 “未授权(unauthorized)” 响应的缓存时间。
--authorization-webhook-config-file string
包含 Webhook 配置的文件,其格式为 kubeconfig,
与 --authorization-mode=Webhook 一起使用。
API 服务器将查询远程服务,以对 API 服务器的安全端口的访问执行鉴权。
--authorization-webhook-version string 默认值:"v1beta1"
与 Webhook 之间交换 authorization.k8s.io SubjectAccessReview 时使用的 API 版本。
--azure-container-registry-config string
包含 Azure 容器仓库配置信息的文件的路径。
--bind-address string 默认值:"0.0.0.0"
用来监听 --secure-port
端口的 IP 地址。
集群的其余部分以及 CLI/web 客户端必须可以访问所关联的接口。
如果为空白或未指定地址(0.0.0.0 或 :: ),则将使用所有接口。
--cert-dir string 默认值:"/var/run/kubernetes"
TLS 证书所在的目录。
如果提供了 --tls-cert-file
和 --tls-private-key-file
标志值,则将忽略此标志。
--client-ca-file string
如果已设置,则使用与客户端证书的 CommonName 对应的标识对任何出示由
client-ca 文件中的授权机构之一签名的客户端证书的请求进行身份验证。
--cloud-config string
云厂商配置文件的路径。空字符串表示无配置文件。
--cloud-provider string
云服务提供商。空字符串表示没有云厂商。
--cloud-provider-gce-l7lb-src-cidrs cidrs 默认值:"130.211.0.0/22,35.191.0.0/16"
在 GCE 防火墙中打开 CIDR,以进行第 7 层负载均衡流量代理和健康状况检查。
--contention-profiling
如果启用了性能分析,则启用锁争用性能分析。
--cors-allowed-origins strings
CORS 允许的来源清单,以逗号分隔。
允许的来源可以是支持子域匹配的正则表达式。
如果此列表为空,则不会启用 CORS。
--default-not-ready-toleration-seconds int 默认值:300
对污点 NotReady:NoExecute 的容忍时长(以秒计)。
默认情况下这一容忍度会被添加到尚未具有此容忍度的每个 pod 中。
--default-unreachable-toleration-seconds int 默认值:300
对污点 Unreachable:NoExecute 的容忍时长(以秒计)
默认情况下这一容忍度会被添加到尚未具有此容忍度的每个 pod 中。
--default-watch-cache-size int 默认值:100
默认监听(watch)缓存大小。
如果为零,则将为没有设置默认监视大小的资源禁用监视缓存。
--delete-collection-workers int 默认值: 1
为 DeleteCollection 调用而产生的工作线程数。
这些用于加速名字空间清理。
--disable-admission-plugins strings
尽管位于默认启用的插件列表中(NamespaceLifecycle、LimitRanger、ServiceAccount、TaintNodesByCondition、PodSecurity、Priority、DefaultTolerationSeconds、DefaultStorageClass、StorageObjectInUseProtection、PersistentVolumeClaimResize、RuntimeClass、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、MutatingAdmissionWebhook、ValidatingAdmissionWebhook、ResourceQuota)仍须被禁用的插件。
取值为逗号分隔的准入插件列表:AlwaysAdmit、AlwaysDeny、AlwaysPullImages、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、DefaultStorageClass、DefaultTolerationSeconds、DenyServiceExternalIPs、EventRateLimit、ExtendedResourceToleration、ImagePolicyWebhook、LimitPodHardAntiAffinityTopology、LimitRanger、MutatingAdmissionWebhook、NamespaceAutoProvision、NamespaceExists、NamespaceLifecycle、NodeRestriction、OwnerReferencesPermissionEnforcement、PersistentVolumeClaimResize、PersistentVolumeLabel、PodNodeSelector、PodSecurity、PodSecurityPolicy、PodTolerationRestriction、Priority、ResourceQuota、RuntimeClass、SecurityContextDeny、ServiceAccount、StorageObjectInUseProtection、TaintNodesByCondition、ValidatingAdmissionWebhook。
该标志中插件的顺序无关紧要。
--disabled-metrics strings
此标志为行为不正确的度量指标提供一种处理方案。
你必须提供完全限定的指标名称才能将其禁止。
声明:禁用度量值的行为优先于显示已隐藏的度量值。
--egress-selector-config-file string
带有 API 服务器出站选择器配置的文件。
--enable-admission-plugins stringSlice
除了默认启用的插件(NamespaceLifecycle、LimitRanger、ServiceAccount、TaintNodesByCondition、PodSecurity、Priority、DefaultTolerationSeconds、DefaultStorageClass、StorageObjectInUseProtection、PersistentVolumeClaimResize、RuntimeClass、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、MutatingAdmissionWebhook、ValidatingAdmissionWebhook、ResourceQuota)之外要启用的插件
取值为逗号分隔的准入插件列表:AlwaysAdmit、AlwaysDeny、AlwaysPullImages、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、DefaultStorageClass、DefaultTolerationSeconds、DenyServiceExternalIPs、EventRateLimit、ExtendedResourceToleration、ImagePolicyWebhook、LimitPodHardAntiAffinityTopology、LimitRanger、MutatingAdmissionWebhook、NamespaceAutoProvision、NamespaceExists、NamespaceLifecycle、NodeRestriction、OwnerReferencesPermissionEnforcement、PersistentVolumeClaimResize、PersistentVolumeLabel、PodNodeSelector、PodSecurity、PodSecurityPolicy、PodTolerationRestriction、Priority、ResourceQuota、RuntimeClass、SecurityContextDeny、ServiceAccount、StorageObjectInUseProtection、TaintNodesByCondition、ValidatingAdmissionWebhook
该标志中插件的顺序无关紧要。
--enable-aggregator-routing
允许聚合器将请求路由到端点 IP 而非集群 IP。
--enable-bootstrap-token-auth
启用以允许将 "kube-system" 名字空间中类型为 "bootstrap.kubernetes.io/token"
的 Secret 用于 TLS 引导身份验证。
--enable-garbage-collector 默认值:true
启用通用垃圾收集器。必须与 kube-controller-manager 的相应标志同步。
--enable-priority-and-fairness 默认值:true
如果为 true 且启用了 APIPriorityAndFairness
特性门控,
请使用增强的处理程序替换 max-in-flight 处理程序,
以便根据优先级和公平性完成排队和调度。
--encryption-provider-config string
包含加密提供程序配置信息的文件,用在 etcd 中所存储的 Secret 上。
--endpoint-reconciler-type string 默认值:"lease"
使用端点协调器(master-count
、lease
或 none
)。
--etcd-cafile string
用于保护 etcd 通信的 SSL 证书颁发机构文件。
--etcd-certfile string
用于保护 etcd 通信的 SSL 证书文件。
--etcd-compaction-interval duration 默认值:5m0s
压缩请求的间隔。
如果为0,则禁用来自 API 服务器的压缩请求。
--etcd-count-metric-poll-period duration 默认值:1m0s
针对每种类型的资源数量轮询 etcd 的频率。
0 值表示禁用度量值收集。
--etcd-db-metric-poll-interval duration 默认值:30s
轮询 etcd 和更新度量值的请求间隔。0 值表示禁用度量值收集。
--etcd-healthcheck-timeout duration
检查 etcd 健康状况时使用的超时时长。
--etcd-keyfile string
用于保护 etcd 通信的 SSL 密钥文件。
--etcd-prefix string 默认值:"/registry"
要在 etcd 中所有资源路径之前添加的前缀。
--etcd-servers strings
要连接的 etcd 服务器列表(scheme://ip:port
),以逗号分隔。
--etcd-servers-overrides strings
etcd 服务器针对每个资源的重载设置,以逗号分隔。
单个替代格式:组/资源#服务器(group/resource#servers),
其中服务器是 URL,以分号分隔。
--event-ttl duration 默认值:1h0m0s
事件的保留时长。
--experimental-logging-sanitization
[试验性功能] 启用此标志时,被标记为敏感的字段(密码、密钥、令牌)都不会被日志输出。
运行时的日志清理可能会引入相当程度的计算开销,因此不应该在产品环境中启用。
--external-hostname string
为此主机生成外部化 UR L时要使用的主机名(例如 Swagger API 文档或 OpenID 发现)。
--feature-gates <逗号分隔的 'key=True|False' 键值对>
一组 key=value 对,用来描述测试性/试验性功能的特性门控。可选项有:
APIListChunking=true|false (BETA - 默认值=true)
APIPriorityAndFairness=true|false (BETA - 默认值=true)
APIResponseCompression=true|false (BETA - 默认值=true)
APIServerIdentity=true|false (ALPHA - 默认值=false)
APIServerTracing=true|false (ALPHA - 默认值=false)
AllAlpha=true|false (ALPHA - 默认值=false)
AllBeta=true|false (BETA - 默认值=false)
AnyVolumeDataSource=true|false (ALPHA - 默认值=false)
AppArmor=true|false (BETA - 默认值=true)
CPUManager=true|false (BETA - 默认值=true)
CPUManagerPolicyOptions=true|false (ALPHA - 默认值=false)
CSIInlineVolume=true|false (BETA - 默认值=true)
CSIMigration=true|false (BETA - 默认值=true)
CSIMigrationAWS=true|false (BETA - 默认值=false)
CSIMigrationAzureDisk=true|false (BETA - 默认值=false)
CSIMigrationAzureFile=true|false (BETA - 默认值=false)
CSIMigrationGCE=true|false (BETA - 默认值=false)
CSIMigrationOpenStack=true|false (BETA - 默认值=true)
CSIMigrationvSphere=true|false (BETA - 默认值=false)
CSIStorageCapacity=true|false (BETA - 默认值=true)
CSIVolumeFSGroupPolicy=true|false (BETA - 默认值=true)
CSIVolumeHealth=true|false (ALPHA - 默认值=false)
CSRDuration=true|false (BETA - 默认值=true)
ConfigurableFSGroupPolicy=true|false (BETA - 默认值=true)
ControllerManagerLeaderMigration=true|false (BETA - 默认值=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
DaemonSetUpdateSurge=true|false (BETA - 默认值=true)
默认值PodTopologySpread=true|false (BETA - 默认值=true)
DelegateFSGroupToCSIDriver=true|false (ALPHA - 默认值=false)
DevicePlugins=true|false (BETA - 默认值=true)
DisableAcceleratorUsageMetrics=true|false (BETA - 默认值=true)
DisableCloudProviders=true|false (ALPHA - 默认值=false)
DownwardAPIHugePages=true|false (BETA - 默认值=false)
EfficientWatchResumption=true|false (BETA - 默认值=true)
EndpointSliceTerminatingCondition=true|false (BETA - 默认值=true)
EphemeralContainers=true|false (ALPHA - 默认值=false)
ExpandCSIVolumes=true|false (BETA - 默认值=true)
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
ExpandPersistentVolumes=true|false (BETA - 默认值=true)
ExpandedDNSConfig=true|false (ALPHA - 默认值=false)
ExperimentalHostUserNamespace默认值ing=true|false (BETA - 默认值=false)
GenericEphemeralVolume=true|false (BETA - 默认值=true)
GracefulNodeShutdown=true|false (BETA - 默认值=true)
HPAContainerMetrics=true|false (ALPHA - 默认值=false)
HPAScaleToZero=true|false (ALPHA - 默认值=false)
IPv6DualStack=true|false (BETA - 默认值=true)
InTreePluginAWSUnregister=true|false (ALPHA - 默认值=false)
InTreePluginAzureDiskUnregister=true|false (ALPHA - 默认值=false)
InTreePluginAzureFileUnregister=true|false (ALPHA - 默认值=false)
InTreePluginGCEUnregister=true|false (ALPHA - 默认值=false)
InTreePluginOpenStackUnregister=true|false (ALPHA - 默认值=false)
InTreePluginvSphereUnregister=true|false (ALPHA - 默认值=false)
IndexedJob=true|false (BETA - 默认值=true)
IngressClassNamespacedParams=true|false (BETA - 默认值=true)
JobTrackingWithFinalizers=true|false (ALPHA - 默认值=false)
KubeletCredentialProviders=true|false (ALPHA - 默认值=false)
KubeletInUserNamespace=true|false (ALPHA - 默认值=false)
KubeletPodResources=true|false (BETA - 默认值=true)
KubeletPodResourcesGetAllocatable=true|false (ALPHA - 默认值=false)
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
LogarithmicScaleDown=true|false (BETA - 默认值=true)
MemoryManager=true|false (BETA - 默认值=true)
MemoryQoS=true|false (ALPHA - 默认值=false)
MixedProtocolLBService=true|false (ALPHA - 默认值=false)
NetworkPolicyEndPort=true|false (BETA - 默认值=true)
NodeSwap=true|false (ALPHA - 默认值=false)
NonPreemptingPriority=true|false (BETA - 默认值=true)
PodAffinityNamespaceSelector=true|false (BETA - 默认值=true)
PodDeletionCost=true|false (BETA - 默认值=true)
PodOverhead=true|false (BETA - 默认值=true)
PodSecurity=true|false (ALPHA - 默认值=false)
PreferNominatedNode=true|false (BETA - 默认值=true)
ProbeTerminationGracePeriod=true|false (BETA - 默认值=false)
ProcMountType=true|false (ALPHA - 默认值=false)
ProxyTerminatingEndpoints=true|false (ALPHA - 默认值=false)
QOSReserved=true|false (ALPHA - 默认值=false)
ReadWriteOncePod=true|false (ALPHA - 默认值=false)
RemainingItemCount=true|false (BETA - 默认值=true)
RemoveSelfLink=true|false (BETA - 默认值=true)
RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
Seccomp默认值=true|false (ALPHA - 默认值=false)
ServiceInternalTrafficPolicy=true|false (BETA - 默认值=true)
ServiceLBNodePortControl=true|false (BETA - 默认值=true)
ServiceLoadBalancerClass=true|false (BETA - 默认值=true)
SizeMemoryBackedVolumes=true|false (BETA - 默认值=true)
StatefulSetMinReadySeconds=true|false (ALPHA - 默认值=false)
StorageVersionAPI=true|false (ALPHA - 默认值=false)
StorageVersionHash=true|false (BETA - 默认值=true)
SuspendJob=true|false (BETA - 默认值=true)
TTLAfterFinished=true|false (BETA - 默认值=true)
TopologyAwareHints=true|false (ALPHA - 默认值=false)
TopologyManager=true|false (BETA - 默认值=true)
VolumeCapacityPriority=true|false (ALPHA - 默认值=false)
WinDSR=true|false (ALPHA - 默认值=false)
WinOverlay=true|false (BETA - 默认值=true)
WindowsHostProcessContainers=true|false (ALPHA - 默认值=false)
--goaway-chance float
为防止 HTTP/2 客户端卡在单个 API 服务器上,可启用随机关闭连接(GOAWAY)。
客户端的其他运行中请求将不会受到影响,并且客户端将重新连接,
可能会在再次通过负载平衡器后登陆到其他 API 服务器上。
此参数设置将发送 GOAWAY 的请求的比例。
具有单个 API 服务器或不使用负载平衡器的群集不应启用此功能。
最小值为0(关闭),最大值为 .02(1/50 请求); 建议使用 .001(1/1000)。
-h, --help
kube-apiserver 的帮助命令
--http2-max-streams-per-connection int
服务器为客户端提供的 HTTP/2 连接中最大流数的限制。
零表示使用 GoLang 的默认值。
--identity-lease-duration-seconds int 默认值:3600
kube-apiserver 租约时长(按秒计),必须是正数。
(当 APIServerIdentity 特性门控被启用时使用此标志值)
--identity-lease-renew-interval-seconds int 默认值:10
kube-apiserver 对其租约进行续期的时间间隔(按秒计),必须是正数。
(当 APIServerIdentity 特性门控被启用时使用此标志值)
--kubelet-certificate-authority string
证书颁发机构的证书文件的路径。
--kubelet-client-certificate string
TLS 的客户端证书文件的路径。
--kubelet-client-key string
TLS 客户端密钥文件的路径。
--kubelet-preferred-address-types strings 默认值:Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP
用于 kubelet 连接的首选 NodeAddressTypes 列表。
--kubelet-timeout duration 默认值:5s
kubelet 操作超时时间。
--kubernetes-service-node-port int
如果非零,那么 Kubernetes 主服务(由 apiserver 创建/维护)将是 NodePort 类型,
使用它作为端口的值。
如果为零,则 Kubernetes 主服务将为 ClusterIP 类型。
--lease-reuse-duration-seconds int 默认值:60
每个租约被重用的时长。
如果此值比较低,可以避免大量对象重用此租约。
注意,如果此值过小,可能导致存储层出现性能问题。
--livez-grace-period duration
此选项代表 API 服务器完成启动序列并生效所需的最长时间。
从 API 服务器的启动时间到这段时间为止,
/livez 将假定未完成的启动后钩子将成功完成,因此返回 true。
--log-backtrace-at traceLocation 默认值::0
当日志机制执行到'文件 :N'时,生成堆栈跟踪。
--log-dir string
如果为非空,则在此目录中写入日志文件。
--log-file string
如果为非空,使用此值作为日志文件。
--log-file-max-size uint 默认值:1800
定义日志文件可以增长到的最大大小。单位为兆字节。
如果值为 0,则最大文件大小为无限制。
--log-flush-frequency duration 默认值:5s
两次日志刷新之间的最大秒数
--logging-format string 默认值:"text"
设置日志格式。允许的格式:"text"。
非默认格式不支持以下标志:--add-dir-header
、--alsologtostderr
、--log-backtrace-at
、--log-dir
、--log-file
、--log-file-max-size
、--logtostderr
、--one-output
、-skip-headers
、-skip-log-headers
、--stderrthreshold
、-vmodule
和 --log-flush-frequency
。
当前非默认选择为 alpha,会随时更改而不会发出警告。
--logtostderr 默认值:true
在标准错误而不是文件中输出日志记录。
--master-service-namespace string 默认值:"default"
已废弃:应该从其中将 Kubernetes 主服务注入到 Pod 中的名字空间。
--max-connection-bytes-per-sec int
如果不为零,则将每个用户连接限制为该数(字节数/秒)。
当前仅适用于长时间运行的请求。
--max-mutating-requests-inflight int 默认值:200
如果 --enable-priority-and-fairness 为 true,那么此值和 --max-requests-inflight 的和将确定服务器的总并发限制(必须是正数)。
否则,该值限制进行中变更类型请求的最大个数,零表示无限制。
--max-requests-inflight int 默认值:400
如果 --enable-priority-and-fairness 为 true,那么此值和 --max-mutating-requests-inflight 的和将确定服务器的总并发限制(必须是正数)。
否则,该值限制进行中非变更类型请求的最大个数,零表示无限制。
--min-request-timeout int 默认值:1800
可选字段,表示处理程序在请求超时前,必须保持其处于打开状态的最小秒数。
当前只对监听(Watch)请求的处理程序有效,它基于这个值选择一个随机数作为连接超时值,
以达到分散负载的目的。
--oidc-ca-file string
如果设置该值,将会使用 oidc-ca-file 中的机构之一对 OpenID 服务的证书进行验证,
否则将会使用主机的根 CA 对其进行验证。
--oidc-client-id string
OpenID 连接客户端的要使用的客户 ID,如果设置了 oidc-issuer-url,则必须设置这个值。
--oidc-groups-claim string
如果提供该值,这个自定义 OpenID 连接声明将被用来设定用户组。
该声明值需要是一个字符串或字符串数组。
此标志为实验性的,请查阅身份认证相关文档进一步了解详细信息。
--oidc-groups-prefix string
如果提供了此值,则所有组都将以该值作为前缀,以防止与其他身份认证策略冲突。
--oidc-issuer-url string
OpenID 颁发者 URL,只接受 HTTPS 方案。
如果设置该值,它将被用于验证 OIDC JSON Web Token(JWT)。
--oidc-required-claim <逗号分隔的 'key=value' 键值对列表>
描述 ID 令牌中必需声明的键值对。
如果设置此值,则会验证 ID 令牌中存在与该声明匹配的值。
重复此标志以指定多个声明。
--oidc-signing-algs strings 默认值:RS256
允许的 JOSE 非对称签名算法的逗号分隔列表。
若 JWT 所带的 "alg" 标头值不在列表中,则该 JWT 将被拒绝。
取值依据 RFC 7518 https://tools.ietf.org/html/rfc7518#section-3.1 定义。
--oidc-username-claim string 默认值:"sub"
要用作用户名的 OpenID 声明。
请注意,除默认声明("sub")以外的其他声明不能保证是唯一且不可变的。
此标志是实验性的,请参阅身份认证文档以获取更多详细信息。
--oidc-username-prefix string
如果提供,则所有用户名都将以该值作为前缀。
如果未提供,则除 "email" 之外的用户名声明都会添加颁发者 URL 作为前缀,以避免冲突。
要略过添加前缀处理,请设置值为 "-"。
--one-output
此标志为真时,日志只会被写入到其原生的严重性级别中(而不是同时写到所有较低
严重性级别中)。
--permit-address-sharing 默认值:false
若此标志为 true,则使用 SO_REUSEADDR 来绑定端口。
这样设置可以同时绑定到用通配符表示的类似 0.0.0.0 这种 IP 地址,
以及特定的 IP 地址。也可以避免等待内核释放 TIME_WAIT 状态的套接字。
--permit-port-sharing 默认值:false
如果为 true,则在绑定端口时将使用 SO_REUSEPORT ,
这样多个实例可以绑定到同一地址和端口上。
--profiling 默认值:true
通过 Web 接口 host:port/debug/pprof/
启用性能分析。
--proxy-client-cert-file string
当必须调用外部程序以处理请求时,用于证明聚合器或者 kube-apiserver 的身份的客户端证书。
包括代理转发到用户 api-server 的请求和调用 Webhook 准入控制插件的请求。
Kubernetes 期望此证书包含来自于 --requestheader-client-ca-file 标志中所给 CA 的签名。
该 CA 在 kube-system 命名空间的 "extension-apiserver-authentication" ConfigMap 中公开。
从 kube-aggregator 收到调用的组件应该使用该 CA 进行各自的双向 TLS 验证。
--proxy-client-key-file string
当必须调用外部程序来处理请求时,用来证明聚合器或者 kube-apiserver 的身份的客户端私钥。
这包括代理转发给用户 api-server 的请求和调用 Webhook 准入控制插件的请求。
--request-timeout duration 默认值:1m0s
可选字段,指示处理程序在超时之前必须保持打开请求的持续时间。
这是请求的默认请求超时,但对于特定类型的请求,可能会被
--min-request-timeout
等标志覆盖。
--requestheader-allowed-names strings
此值为客户端证书通用名称(Common Name)的列表;表中所列的表项可以用来提供用户名,
方式是使用 --requestheader-username-headers
所指定的头部。
如果为空,能够通过 --requestheader-client-ca-file
中机构
认证的客户端证书都是被允许的。
--requestheader-client-ca-file string
在信任请求头中以 --requestheader-username-headers
指示的用户名之前,
用于验证接入请求中客户端证书的根证书包。
警告:一般不要假定传入请求已被授权。
--requestheader-extra-headers-prefix strings
用于查验请求头部的前缀列表。建议使用 X-Remote-Extra-
。
--requestheader-group-headers strings
用于查验用户组的请求头部列表。建议使用 X-Remote-Group
。
--requestheader-username-headers strings
用于查验用户名的请求头头列表。建议使用 X-Remote-User
。
--runtime-config <逗号分隔的 'key=value' 对列表>
一组启用或禁用内置 API 的键值对。支持的选项包括:
v1=true|false(针对核心 API 组)
<group>/<version>=true|false(针对特定 API 组和版本,例如:apps/v1=true)
api/all=true|false 控制所有 API 版本
api/ga=true|false 控制所有 v[0-9]+ API 版本
api/beta=true|false 控制所有 v[0-9]+beta[0-9]+ API 版本
api/alpha=true|false 控制所有 v[0-9]+alpha[0-9]+ API 版本
api/legacy 已弃用,并将在以后的版本中删除
--secure-port int 默认值:6443
带身份验证和鉴权机制的 HTTPS 服务端口。
不能用 0 关闭。
--service-account-extend-token-expiration 默认值:true
在生成令牌时,启用投射服务帐户到期时间扩展,
这有助于从旧版令牌安全地过渡到绑定的服务帐户令牌功能。
如果启用此标志,则准入插件注入的令牌的过期时间将延长至 1 年,以防止过渡期间发生意外故障,
并忽略 service-account-max-token-expiration 的值。
--service-account-issuer strings
服务帐号令牌颁发者的标识符。
颁发者将在已办法令牌的 "iss" 声明中检查此标识符。
此值为字符串或 URI。
如果根据 OpenID Discovery 1.0 规范检查此选项不是有效的 URI,则即使特性门控设置为 true,
ServiceAccountIssuerDiscovery 功能也将保持禁用状态。
强烈建议该值符合 OpenID 规范:https://openid.net/specs/openid-connect-discovery-1_0.html。
实践中,这意味着 service-account-issuer 取值必须是 HTTPS URL。
还强烈建议此 URL 能够在 {service-account-issuer}/.well-known/openid-configuration
处提供 OpenID 发现文档。
当此值被多次指定时,第一次的值用于生成令牌,所有的值用于确定接受哪些发行人。
--service-account-jwks-uri string
覆盖 /.well-known/openid-configuration
提供的发现文档中 JSON Web 密钥集的 URI。
如果发现文档和密钥集是通过 API 服务器外部
(而非自动检测到或被外部主机名覆盖)之外的 URL 提供给依赖方的,则此标志很有用。
仅在启用 ServiceAccountIssuerDiscovery 特性门控的情况下有效。
--service-account-key-file strings
包含 PEM 编码的 x509 RSA 或 ECDSA 私钥或公钥的文件,用于验证 ServiceAccount 令牌。
指定的文件可以包含多个键,并且可以使用不同的文件多次指定标志。
如果未指定,则使用 --tls-private-key-file
。
提供 --service-account-signing-key
时必须指定。
--service-account-lookup 默认值:true
如果为 true,则在身份认证时验证 etcd 中是否存在 ServiceAccount 令牌。
--service-account-max-token-expiration duration
服务帐户令牌发布者创建的令牌的最长有效期。
如果请求有效期大于此值的有效令牌请求,将使用此值的有效期颁发令牌。
--service-account-signing-key-file string
包含服务帐户令牌颁发者当前私钥的文件的路径。
颁发者将使用此私钥签署所颁发的 ID 令牌。
--service-cluster-ip-range string
CIDR 表示的 IP 范围用来为服务分配集群 IP。
此地址不得与指定给节点或 Pod 的任何 IP 范围重叠。
--service-node-port-range <形式为 'N1-N2' 的字符串> 默认值:30000-32767
保留给具有 NodePort 可见性的服务的端口范围。
例如:"30000-32767"。范围的两端都包括在内。
--show-hidden-metrics-for-version string
你要显示隐藏指标的先前版本。仅先前的次要版本有意义,不允许其他值。
格式为 <major>.<minor>,例如:"1.16"。
这种格式的目的是确保你有机会注意到下一个版本是否隐藏了其他指标,
而不是在此之后将它们从发行版中永久删除时感到惊讶。
--shutdown-delay-duration duration
延迟终止时间。在此期间,服务器将继续正常处理请求。
端点 /healthz 和 /livez 将返回成功,但是 /readyz 立即返回失败。
在此延迟过去之后,将开始正常终止。
这可用于允许负载平衡器停止向该服务器发送流量。
--skip-headers
如果为 true,日志消息中避免标题前缀。
--skip-log-headers
如果为 true,则在打开日志文件时避免标题。
--stderrthreshold int 默认值:2
将达到或超过此阈值的日志写到标准错误输出
--storage-backend string
持久化存储后端。选项:"etcd3"(默认)。
--storage-media-type string 默认值:"application/vnd.kubernetes.protobuf"
用于在存储中存储对象的媒体类型。
某些资源或存储后端可能仅支持特定的媒体类型,并且将忽略此设置。
--strict-transport-security-directives strings
为 HSTS 所设置的指令列表,用逗号分隔。
如果此列表为空,则不会添加 HSTS 指令。
例如: 'max-age=31536000,includeSubDomains,preload'
--tls-cert-file string
包含用于 HTTPS 的默认 x509 证书的文件。(CA 证书(如果有)在服务器证书之后并置)。
如果启用了 HTTPS 服务,并且未提供 --tls-cert-file
和
--tls-private-key-file
,
为公共地址生成一个自签名证书和密钥,并将其保存到 --cert-dir
指定的目录中。
--tls-cipher-suites strings
服务器的密码套件的列表,以逗号分隔。如果省略,将使用默认的 Go 密码套件。
首选值:
TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256、TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256、TLS_RSA_WITH_3DES_EDE_CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHA、TLS_RSA_WITH_AES_128_GCM_SHA256、 TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384.
不安全的值有:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_ECDSA_WITH_RC4_128_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_RSA_WITH_RC4_128_SHA、TLS_RSA_WITH_AES_128_CBC_SHA256、TLS_RSA_WITH_RC4_128_SHA。
--tls-min-version string
支持的最低 TLS 版本。可能的值:VersionTLS10,VersionTLS11,VersionTLS12,VersionTLS13
--tls-private-key-file string
包含匹配 --tls-cert-file
的 x509 证书私钥的文件。
--tls-sni-cert-key string 默认值: []
一对 x509 证书和私钥文件路径,(可选)后缀为全限定域名的域名模式列表,可以使用带有通配符的前缀。
域模式也允许使用 IP 地址,但仅当 apiserver 对客户端请求的IP地址具有可见性时,才应使用 IP。
如果未提供域模式,则提取证书的名称。
非通配符匹配优先于通配符匹配,显式域模式优先于提取出的名称。
对于多个密钥/证书对,请多次使用 --tls-sni-cert-key
。
示例:"example.crt,example.key" 或 "foo.crt,foo.key:\*.foo.com,foo.com"。
--token-auth-file string
如果设置该值,这个文件将被用于通过令牌认证来保护 API 服务的安全端口。
--tracing-config-file string
包含 API 服务器跟踪配置的文件。
-v, --v int
日志级别详细程度的数字。
--version version[=true]
打印版本信息并退出
--vmodule <用逗号分隔的多个 'pattern=N' 配置字符串>
以逗号分隔的 pattern=N
设置列表,用于文件过滤的日志记录。
--watch-cache 默认值:true
在 API 服务器中启用监视缓存。
--watch-cache-sizes strings
某些资源(Pods、Nodes 等)的监视缓存大小设置,以逗号分隔。
每个资源对应的设置格式:resource[.group]#size
,其中
resource
为小写复数(无版本),
对于 apiVersion v1(旧版核心 API)的资源要省略 group
,
对其它资源要给出 group
;size 为一个数字
。
启用 watch-cache
时,此功能生效。
某些资源(replicationcontrollers
、endpoints
、
nodes
、pods
、services
、
apiservices.apiregistration.k8s.io
)
具有通过启发式设置的系统默认值,其他资源默认为
default-watch-cache-size。
11.4 - kube-controller-manager
简介
Kubernetes 控制器管理器是一个守护进程,内嵌随 Kubernetes 一起发布的核心控制回路。
在机器人和自动化的应用中,控制回路是一个永不休止的循环,用于调节系统状态。
在 Kubernetes 中,每个控制器是一个控制回路,通过 API 服务器监视集群的共享状态,
并尝试进行更改以将当前状态转为期望状态。
目前,Kubernetes 自带的控制器例子包括副本控制器、节点控制器、命名空间控制器和服务账号控制器等。
kube-controller-manager [flags]
选项
--add-dir-header
若为 true,将文件目录添加到日志消息的头部。
--allocate-node-cidrs
基于云驱动来为 Pod 分配和设置子网掩码。
--allow-metric-labels stringToString 默认值:""
从度量值标签到准许值列表的映射。键名的格式为<MetricName>,<LabelName>。
准许值的格式为<allowed_value>,<allowed_value>...。
例如,metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3'
metric2,label='v1,v2,v3'
。
--alsologtostderr
在向文件输出日志的同时,也将日志写到标准输出。
--attach-detach-reconcile-sync-period duration 默认值:1m0s
协调器(reconciler)在相邻两次对存储卷进行挂载和解除挂载操作之间的等待时间。
此时长必须长于 1 秒钟。此值设置为大于默认值时,可能导致存储卷无法与 Pods 匹配。
--authentication-kubeconfig string
此标志值为一个 kubeconfig 文件的路径名。该文件中包含与某 Kubernetes “核心”
服务器相关的信息,并支持足够的权限以创建 tokenreviews.authentication.k8s.io。
此选项是可选的。如果设置为空值,所有令牌请求都会被认作匿名请求,
Kubernetes 也不再在集群中查找客户端的 CA 证书信息。
--authentication-skip-lookup
此值为 false 时,通过 authentication-kubeconfig 参数所指定的文件会被用来
检索集群中缺失的身份认证配置信息。
--authentication-token-webhook-cache-ttl duration 默认值:10s
对 Webhook 令牌认证设施返回结果的缓存时长。
--authentication-tolerate-lookup-failure
此值为 true 时,即使无法从集群中检索到缺失的身份认证配置信息也无大碍。
需要注意的是,这样设置可能导致所有请求都被视作匿名请求。
--authorization-always-allow-paths strings 默认值:"/healthz,/readyz,/livez"
鉴权过程中会忽略的一个 HTTP 路径列表。
换言之,控制器管理器会对列表中路径的访问进行授权,并且无须征得
Kubernetes “核心” 服务器同意。
--authorization-kubeconfig string
包含 Kubernetes “核心” 服务器信息的 kubeconfig 文件路径,
所包含信息具有创建 subjectaccessreviews.authorization.k8s.io 的足够权限。
此参数是可选的。如果配置为空字符串,未被鉴权模块所忽略的请求都会被禁止。
--authorization-webhook-cache-authorized-ttl duration 默认值:10s
对 Webhook 形式鉴权组件所返回的“已授权(Authorized)”响应的缓存时长。
--authorization-webhook-cache-unauthorized-ttl duration 默认值:10s
对 Webhook 形式鉴权组件所返回的“未授权(Unauthorized)”响应的缓存时长。
--azure-container-registry-config string
指向包含 Azure 容器仓库配置信息的文件的路径名。
--bind-address ip 默认值:0.0.0.0
针对 --secure-port
端口上请求执行监听操作的 IP 地址。
所对应的网络接口必须从集群中其它位置可访问(含命令行及 Web 客户端)。
如果此值为空或者设定为非特定地址(0.0.0.0
或 ::
),
意味着所有网络接口都在监听范围。
--cert-dir string
TLS 证书所在的目录。如果提供了 --tls-cert-file
和
--tls-private-key-file
,此标志会被忽略。
--cidr-allocator-type string 默认值:"RangeAllocator"
要使用的 CIDR 分配器类型。
--client-ca-file string
如果设置了此标志,对于所有能够提供客户端证书的请求,若该证书由
--client-ca-file
中所给机构之一签署,则该请求会被
成功认证为客户端证书中 CommonName 所标识的实体。
--cloud-config string
云驱动程序配置文件的路径。空字符串表示没有配置文件。
--cloud-provider string
云服务的提供者。空字符串表示没有对应的提供者(驱动)。
--cluster-cidr string
集群中 Pods 的 CIDR 范围。要求 --allocate-node-cidrs
标志为 true。
--cluster-name string 默认值:"kubernetes"
集群实例的前缀。
--cluster-signing-cert-file string
包含 PEM 编码格式的 X509 CA 证书的文件名。该证书用来发放集群范围的证书。
如果设置了此标志,则不能指定更具体的--cluster-signing-*
标志。
--cluster-signing-duration duration 默认值:8760h0m0s
所签名证书的有效期限。每个 CSR 可以通过设置 spec.expirationSeconds 来请求更短的证书。
--cluster-signing-key-file string
包含 PEM 编码的 RSA 或 ECDSA 私钥的文件名。该私钥用来对集群范围证书签名。
若指定了此选项,则不可再设置 --cluster-signing-*
参数。
--cluster-signing-kube-apiserver-client-cert-file string
包含 PEM 编码的 X509 CA 证书的文件名,
该证书用于为 kubernetes.io/kube-apiserver-client 签署者颁发证书。
如果指定,则不得设置 --cluster-signing-{cert,key}-file
。
--cluster-signing-kube-apiserver-client-key-file string
包含 PEM 编码的 RSA 或 ECDSA 私钥的文件名,
该私钥用于为 kubernetes.io/kube-apiserver-client 签署者签名证书。
如果指定,则不得设置 --cluster-signing-{cert,key}-file
。
--cluster-signing-kubelet-client-cert-file string
包含 PEM 编码的 X509 CA 证书的文件名,
该证书用于为 kubernetes.io/kube-apiserver-client-kubelet 签署者颁发证书。
如果指定,则不得设置 --cluster-signing-{cert,key}-file
。
--cluster-signing-kubelet-client-key-file string
包含 PEM 编码的 RSA 或 ECDSA 私钥的文件名,
该私钥用于为 kubernetes.io/kube-apiserver-client-kubelet 签署者签名证书。
如果指定,则不得设置 --cluster-signing-{cert,key}-file
。
--cluster-signing-kubelet-serving-cert-file string
包含 PEM 编码的 X509 CA 证书的文件名,
该证书用于为 kubernetes.io/kubelet-serving 签署者颁发证书。
如果指定,则不得设置 --cluster-signing-{cert,key}-file。
--cluster-signing-kubelet-serving-key-file string
包含 PEM 编码的 RSA或ECDSA 私钥的文件名,
该私钥用于对 kubernetes.io/kubelet-serving 签署者的证书进行签名。
如果指定,则不得设置 --cluster-signing-{cert,key}-file
。
--cluster-signing-legacy-unknown-cert-file string
包含 PEM 编码的 X509 CA 证书的文件名,
用于为 kubernetes.io/legacy-unknown 签署者颁发证书。
如果指定,则不得设置 --cluster-signing-{cert,key}-file
。
--cluster-signing-legacy-unknown-key-file string
包含 PEM 编码的 RSA 或 ECDSA 私钥的文件名,
用于为 kubernetes.io/legacy-unknown 签署者签名证书。
如果指定,则不得设置 --cluster-signing-{cert,key}-file
。
--concurrent-deployment-syncs int32 默认值:5
可以并发同步的 Deployment 对象个数。数值越大意味着对 Deployment 的响应越及时,
同时也意味着更大的 CPU(和网络带宽)压力。
--concurrent-endpoint-syncs int32 默认值:5
可以并发执行的 Endpoints 同步操作个数。数值越大意味着更快的 Endpoints 更新操作,
同时也意味着更大的 CPU (和网络)压力。
--concurrent-gc-syncs int32 默认值:20
可以并发同步的垃圾收集工作线程个数。
--concurrent-namespace-syncs int32 默认值:10
可以并发同步的 Namespace 对象个数。较大的数值意味着更快的名字空间终结操作,
不过也意味着更多的 CPU (和网络)占用。
--concurrent-rc-syncs int32 默认值:5
可以并发同步的副本控制器对象个数。较大的数值意味着更快的副本管理操作,
不过也意味着更多的 CPU (和网络)占用。
--concurrent-replicaset-syncs int32 默认值:5
可以并发同步的 ReplicaSet 个数。数值越大意味着副本管理的响应速度越快,
同时也意味着更多的 CPU (和网络)占用。
--concurrent-resource-quota-syncs int32 默认值:5
可以并发同步的 ResourceQuota 对象个数。数值越大,配额管理的响应速度越快,
不过对 CPU (和网络)的占用也越高。
--concurrent-service-endpoint-syncs int32 默认值:5
可以并发执行的服务端点同步操作个数。数值越大,端点片段(Endpoint Slice)
的更新速度越快,不过对 CPU (和网络)的占用也越高。默认值为 5。
--concurrent-service-syncs int32 默认值:1
可以并发同步的 Service 对象个数。数值越大,服务管理的响应速度越快,
不过对 CPU (和网络)的占用也越高。
--concurrent-serviceaccount-token-syncs int32 默认值:5
可以并发同步的服务账号令牌对象个数。数值越大,令牌生成的速度越快,
不过对 CPU (和网络)的占用也越高。
--concurrent-statefulset-syncs int32 默认值:5
可以并发同步的 StatefulSet 对象个数。数值越大,StatefulSet 管理的响应速度越快,
不过对 CPU (和网络)的占用也越高。
--concurrent-ttl-after-finished-syncs int32 默认值:5
可以并发同步的 TTL-after-finished 控制器线程个数。
--configure-cloud-routes 默认值:true
决定是否由 --allocate-node-cidrs
所分配的 CIDR 要通过云驱动程序来配置。
--contention-profiling
在启用了性能分析(profiling)时,也启用锁竞争情况分析。
--controller-start-interval duration
在两次启动控制器管理器之间的时间间隔。
--controllers strings 默认值:[*]
要启用的控制器列表。\*
表示启用所有默认启用的控制器;
foo
启用名为 foo 的控制器;
-foo
表示禁用名为 foo 的控制器。
控制器的全集:attachdetach、bootstrapsigner、cloud-node-lifecycle、clusterrole-aggregation、cronjob、csrapproving、csrcleaner、csrsigning、daemonset、deployment、disruption、endpoint、endpointslice、endpointslicemirroring、ephemeral-volume、garbagecollector、horizontalpodautoscaling、job、namespace、nodeipam、nodelifecycle、persistentvolume-binder、persistentvolume-expander、podgc、pv-protection、pvc-protection、replicaset、replicationcontroller、resourcequota、root-ca-cert-publisher、route、service、serviceaccount、serviceaccount-token、statefulset、tokencleaner、ttl、ttl-after-finished
默认禁用的控制器有:bootstrapsigner 和 tokencleaner。
--deployment-controller-sync-period duration 默认值:30s
Deployment 资源的同步周期。
--disable-attach-detach-reconcile-sync
禁用卷挂接/解挂调节器的同步。禁用此同步可能导致卷存储与 Pod 之间出现错位。
请小心使用。
--disabled-metrics strings
此标志提供对行为异常的度量值的防控措施。你必须提供度量值的
完全限定名称才能将其禁用。声明 :禁用度量值的操作比显示隐藏度量值
的操作优先级高。
--enable-dynamic-provisioning 默认值:true
在环境允许的情况下启用动态卷制备。
--enable-garbage-collector 默认值:true
启用通用垃圾收集器。必须与 kube-apiserver 中对应的标志一致。
--enable-hostpath-provisioner
在没有云驱动程序的情况下,启用 HostPath 持久卷的制备。
此参数便于对卷供应功能进行开发和测试。HostPath 卷的制备并非受支持的功能特性,
在多节点的集群中也无法工作,因此除了开发和测试环境中不应使用。
--enable-leader-migration
此标志决定是否启用控制器领导者迁移。
--enable-taint-manager 默认值:true
警告:此为Beta 阶段特性。设置为 true 时会启用 NoExecute 污点,
并在所有标记了此污点的节点上逐出所有无法忍受该污点的 Pods。
--endpoint-updates-batch-period duration
端点(Endpoint)批量更新周期时长。对 Pods 变更的处理会被延迟,
以便将其与即将到来的更新操作合并,从而减少端点更新操作次数。
较大的数值意味着端点更新的迟滞时间会增长,也意味着所生成的端点版本个数会变少。
--endpointslice-updates-batch-period duration
端点片段(Endpoint Slice)批量更新周期时长。对 Pods 变更的处理会被延迟,
以便将其与即将到来的更新操作合并,从而减少端点更新操作次数。
较大的数值意味着端点更新的迟滞时间会增长,也意味着所生成的端点版本个数会变少。
--experimental-logging-sanitization
[试验性功能] 当启用此标志时,被标记为敏感的字段(密码、密钥、令牌)不会被日志输出。
运行时的日志清理操作可能会引入相当程度的计算开销,因此不应在生产环境中启用。
--external-cloud-volume-plugin string
当云驱动程序设置为 external 时要使用的插件名称。此字符串可以为空。
只能在云驱动程序为 external 时设置。目前用来保证节点控制器和卷控制器能够
在三种云驱动上正常工作。
--feature-gates <逗号分隔的 'key=True|False' 对列表>
一组 key=value 对,用来描述测试性/试验性功能的特性门控(Feature Gate)。可选项有:
APIListChunking=true|false (BETA - 默认值=true)
APIPriorityAndFairness=true|false (BETA - 默认值=true)
APIResponseCompression=true|false (BETA - 默认值=true)
APIServerIdentity=true|false (ALPHA - 默认值=false)
APIServerTracing=true|false (ALPHA - 默认值=false)
AllAlpha=true|false (ALPHA - 默认值=false)
AllBeta=true|false (BETA - 默认值=false)
AnyVolumeDataSource=true|false (ALPHA - 默认值=false)
AppArmor=true|false (BETA - 默认值=true)
CPUManager=true|false (BETA - 默认值=true)
CPUManagerPolicyOptions=true|false (ALPHA - 默认值=false)
CSIInlineVolume=true|false (BETA - 默认值=true)
CSIMigration=true|false (BETA - 默认值=true)
CSIMigrationAWS=true|false (BETA - 默认值=false)
CSIMigrationAzureDisk=true|false (BETA - 默认值=false)
CSIMigrationAzureFile=true|false (BETA - 默认值=false)
CSIMigrationGCE=true|false (BETA - 默认值=false)
CSIMigrationOpenStack=true|false (BETA - 默认值=true)
CSIMigrationvSphere=true|false (BETA - 默认值=false)
CSIStorageCapacity=true|false (BETA - 默认值=true)
CSIVolumeFSGroupPolicy=true|false (BETA - 默认值=true)
CSIVolumeHealth=true|false (ALPHA - 默认值=false)
CSRDuration=true|false (BETA - 默认值=true)
ConfigurableFSGroupPolicy=true|false (BETA - 默认值=true)
ControllerManagerLeaderMigration=true|false (BETA - 默认值=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
DaemonSetUpdateSurge=true|false (BETA - 默认值=true)
默认值PodTopologySpread=true|false (BETA - 默认值=true)
DelegateFSGroupToCSIDriver=true|false (ALPHA - 默认值=false)
DevicePlugins=true|false (BETA - 默认值=true)
DisableAcceleratorUsageMetrics=true|false (BETA - 默认值=true)
DisableCloudProviders=true|false (ALPHA - 默认值=false)
DownwardAPIHugePages=true|false (BETA - 默认值=false)
EfficientWatchResumption=true|false (BETA - 默认值=true)
EndpointSliceTerminatingCondition=true|false (BETA - 默认值=true)
EphemeralContainers=true|false (ALPHA - 默认值=false)
ExpandCSIVolumes=true|false (BETA - 默认值=true)
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
ExpandPersistentVolumes=true|false (BETA - 默认值=true)
ExpandedDNSConfig=true|false (ALPHA - 默认值=false)
ExperimentalHostUserNamespace默认值ing=true|false (BETA - 默认值=false)
GenericEphemeralVolume=true|false (BETA - 默认值=true)
GracefulNodeShutdown=true|false (BETA - 默认值=true)
HPAContainerMetrics=true|false (ALPHA - 默认值=false)
HPAScaleToZero=true|false (ALPHA - 默认值=false)
IPv6DualStack=true|false (BETA - 默认值=true)
InTreePluginAWSUnregister=true|false (ALPHA - 默认值=false)
InTreePluginAzureDiskUnregister=true|false (ALPHA - 默认值=false)
InTreePluginAzureFileUnregister=true|false (ALPHA - 默认值=false)
InTreePluginGCEUnregister=true|false (ALPHA - 默认值=false)
InTreePluginOpenStackUnregister=true|false (ALPHA - 默认值=false)
InTreePluginvSphereUnregister=true|false (ALPHA - 默认值=false)
IndexedJob=true|false (BETA - 默认值=true)
IngressClassNamespacedParams=true|false (BETA - 默认值=true)
JobTrackingWithFinalizers=true|false (ALPHA - 默认值=false)
KubeletCredentialProviders=true|false (ALPHA - 默认值=false)
KubeletInUserNamespace=true|false (ALPHA - 默认值=false)
KubeletPodResources=true|false (BETA - 默认值=true)
KubeletPodResourcesGetAllocatable=true|false (ALPHA - 默认值=false)
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
LogarithmicScaleDown=true|false (BETA - 默认值=true)
MemoryManager=true|false (BETA - 默认值=true)
MemoryQoS=true|false (ALPHA - 默认值=false)
MixedProtocolLBService=true|false (ALPHA - 默认值=false)
NetworkPolicyEndPort=true|false (BETA - 默认值=true)
NodeSwap=true|false (ALPHA - 默认值=false)
NonPreemptingPriority=true|false (BETA - 默认值=true)
PodAffinityNamespaceSelector=true|false (BETA - 默认值=true)
PodDeletionCost=true|false (BETA - 默认值=true)
PodOverhead=true|false (BETA - 默认值=true)
PodSecurity=true|false (ALPHA - 默认值=false)
PreferNominatedNode=true|false (BETA - 默认值=true)
ProbeTerminationGracePeriod=true|false (BETA - 默认值=false)
ProcMountType=true|false (ALPHA - 默认值=false)
ProxyTerminatingEndpoints=true|false (ALPHA - 默认值=false)
QOSReserved=true|false (ALPHA - 默认值=false)
ReadWriteOncePod=true|false (ALPHA - 默认值=false)
RemainingItemCount=true|false (BETA - 默认值=true)
RemoveSelfLink=true|false (BETA - 默认值=true)
RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
Seccomp默认值=true|false (ALPHA - 默认值=false)
ServiceInternalTrafficPolicy=true|false (BETA - 默认值=true)
ServiceLBNodePortControl=true|false (BETA - 默认值=true)
ServiceLoadBalancerClass=true|false (BETA - 默认值=true)
SizeMemoryBackedVolumes=true|false (BETA - 默认值=true)
StatefulSetMinReadySeconds=true|false (ALPHA - 默认值=false)
StorageVersionAPI=true|false (ALPHA - 默认值=false)
StorageVersionHash=true|false (BETA - 默认值=true)
SuspendJob=true|false (BETA - 默认值=true)
TTLAfterFinished=true|false (BETA - 默认值=true)
TopologyAwareHints=true|false (ALPHA - 默认值=false)
TopologyManager=true|false (BETA - 默认值=true)
VolumeCapacityPriority=true|false (ALPHA - 默认值=false)
WinDSR=true|false (ALPHA - 默认值=false)
WinOverlay=true|false (BETA - 默认值=true)
WindowsHostProcessContainers=true|false (ALPHA - 默认值=false)
--flex-volume-plugin-dir string 默认值:"/usr/libexec/kubernetes/kubelet-plugins/volume/exec/"
FlexVolume 插件要搜索第三方卷插件的目录路径全名。
-h, --help
kube-controller-manager 的帮助信息。
--horizontal-pod-autoscaler-cpu-initialization-period duration 默认值:5m0s
Pod 启动之后可以忽略 CPU 采样值的时长。
--horizontal-pod-autoscaler-downscale-stabilization duration 默认值:5m0s
自动扩缩程序的回溯时长。自动扩缩器不会基于在给定的时长内所建议的规模
对负载执行规模缩小的操作。
--horizontal-pod-autoscaler-initial-readiness-delay duration 默认值:30s
Pod 启动之后,在此值所给定的时长内,就绪状态的变化都不会作为初始的就绪状态。
--horizontal-pod-autoscaler-sync-period duration 默认值:15s
水平 Pod 扩缩器对 Pods 数目执行同步操作的周期。
--horizontal-pod-autoscaler-tolerance float 默认值:0.1
此值为目标值与实际值的比值与 1.0 的差值。只有超过此标志所设的阈值时,
HPA 才会考虑执行缩放操作。
--http2-max-streams-per-connection int
服务器为客户端所设置的 HTTP/2 连接中流式连接个数上限。
此值为 0 表示采用 Go 语言库所设置的默认值。
--kube-api-burst int32 默认值:30
与 Kubernetes API 服务器通信时突发峰值请求个数上限。
--kube-api-content-type string 默认值:"application/vnd.kubernetes.protobuf"
向 API 服务器发送请求时使用的内容类型(Content-Type)。
--kube-api-qps float32 默认值:20
与 API 服务器通信时每秒请求数(QPS)限制。
--kubeconfig string
指向 kubeconfig 文件的路径。该文件中包含主控节点位置以及鉴权凭据信息。
--large-cluster-size-threshold int32 默认值:50
节点控制器在执行 Pod 逐出操作逻辑时,基于此标志所设置的节点个数阈值来判断
所在集群是否为大规模集群。当集群规模小于等于此规模时,
--secondary-node-eviction-rate
会被隐式重设为 0。
--leader-elect 默认值:true
在执行主循环之前,启动领导选举(Leader Election)客户端,并尝试获得领导者身份。
在运行多副本组件时启用此标志有助于提高可用性。
--leader-elect-lease-duration duration 默认值:15s
对于未获得领导者身份的节点,在探测到领导者身份需要更迭时需要等待
此标志所设置的时长,才能尝试去获得曾经是领导者但尚未续约的席位。
本质上,这个时长也是现有领导者节点在被其他候选节点替代之前可以停止
的最长时长。只有集群启用了领导者选举机制时,此标志才起作用。
--leader-elect-renew-deadline duration 默认值:10s
当前执行领导者角色的节点在被停止履行领导职责之前可多次尝试续约领导者身份;
此标志给出相邻两次尝试之间的间歇时长。
此值必须小于或等于租期时长(Lease Duration)。
仅在集群启用了领导者选举时有效。
--leader-elect-resource-lock string 默认值:"leases"
在领导者选举期间用于锁定的资源对象的类型。 支持的选项为 "endpoints"、
"configmaps"、"leases"、"endpointsleases" 和 "configmapsleases"。
--leader-elect-resource-name string 默认值:"kube-controller-manager"
在领导者选举期间,用来执行锁操作的资源对象名称。
--leader-elect-resource-namespace string 默认值:"kube-system"
在领导者选举期间,用来执行锁操作的资源对象的名字空间。
--leader-elect-retry-period duration 默认值:2s
尝试获得领导者身份时,客户端在相邻两次尝试之间要等待的时长。
此标志仅在启用了领导者选举的集群中起作用。
--leader-migration-config string
控制器领导者迁移所用的配置文件路径。
此值为空意味着使用控制器管理器的默认配置。
配置文件应该是 controllermanager.config.k8s.io
组、
v1alpha1
版本的 LeaderMigrationConfiguration
结构。
--log-backtrace-at traceLocation 默认值::0
当执行到 file:N
所给的文件和代码行时,日志机制会生成一个调用栈快照。
--log-dir string
此标志为非空字符串时,日志文件会写入到所给的目录中。
--log-file string
此标志为非空字符串时,意味着日志会写入到所给的文件中。
--log-file-max-size uint 默认值:1800
定义日志文件大小的上限。单位是兆字节(MB)。
若此值为 0,则不对日志文件尺寸进行约束。
--log-flush-frequency duration 默认值:5s
将内存中日志数据清除到日志文件中时,相邻两次清除操作之间最大间隔秒数。
--logging-format string 默认值:"text"
设置日志格式。允许的格式:"text"。
非默认格式不支持以下标志:--add-dir-header
、
--alsologtostderr
》、--log-backtrace-at
、
--log-dir
、--log-file
、--log-file-max-size
、
--logtostderr
、--one-output
、--skip-headers
、
--skip-log-headers
、--stderrthreshold
、
--vmodule
、--log-flush-frequency
。
当前非默认选项为 Alpha 阶段,如有更改,恕不另行通知。
--logtostderr 默认值:true
将日志写出到标准错误输出(stderr)而不是写入到日志文件。
--master string
Kubernetes API 服务器的地址。此值会覆盖 kubeconfig 文件中所给的地址。
--max-endpoints-per-slice int32 默认值:100
每个 EndpointSlice 中可以添加的端点个数上限。每个片段中端点个数越多,
得到的片段个数越少,但是片段的规模会变得更大。默认值为 100。
--min-resync-period duration 默认值:12h0m0s
自省程序的重新同步时隔下限。实际时隔长度会在 min-resync-period
和
2 * min-resync-period
之间。
--mirroring-concurrent-service-endpoint-syncs int32 默认值:5
EndpointSliceMirroring 控制器将同时执行的服务端点同步操作数。
较大的数量 = 更快的端点切片更新,但 CPU(和网络)负载更多。 默认为 5。
--mirroring-endpointslice-updates-batch-period duration
EndpointSlice 的长度更新了 EndpointSliceMirroring 控制器的批处理周期。
EndpointSlice 更改的处理将延迟此持续时间,
以使它们与潜在的即将进行的更新结合在一起,并减少 EndpointSlice 更新的总数。
较大的数量 = 较高的端点编程延迟,但是生成的端点修订版本数量较少
--mirroring-max-endpoints-per-subset int32 默认值:1000
EndpointSliceMirroring 控制器将添加到 EndpointSlice 的最大端点数。
每个分片的端点越多,端点分片越少,但资源越大。
--namespace-sync-period duration 默认值:5m0s
对名字空间对象进行同步的周期。
--node-cidr-mask-size int32
集群中节点 CIDR 的掩码长度。对 IPv4 而言默认为 24;对 IPv6 而言默认为 64。
--node-cidr-mask-size-ipv4 int32
在双堆栈(同时支持 IPv4 和 IPv6)的集群中,节点 IPV4 CIDR 掩码长度。默认为 24。
--node-cidr-mask-size-ipv6 int32
在双堆栈(同时支持 IPv4 和 IPv6)的集群中,节点 IPv6 CIDR 掩码长度。默认为 64。
--node-eviction-rate float32 默认值:0.1
当某区域变得不健康,节点失效时,每秒钟可以从此标志所设定的节点
个数上删除 Pods。请参阅 --unhealthy-zone-threshold
以了解“健康”的判定标准。这里的区域(zone)在集群并不跨多个区域时
指的是整个集群。
--node-monitor-grace-period duration 默认值:40s
在将一个 Node 标记为不健康之前允许其无响应的时长上限。
必须比 kubelet 的 nodeStatusUpdateFrequency 大 N 倍;
这里 N 指的是 kubelet 发送节点状态的重试次数。
--node-monitor-period duration 默认值:5s
节点控制器对节点状态进行同步的重复周期。
--node-startup-grace-period duration 默认值:1m0s
在节点启动期间,节点可以处于无响应状态;
但超出此标志所设置的时长仍然无响应则该节点被标记为不健康。
--one-output
如果此标志为 true,则仅将日志写入其自身的严重性级别(而不是同时写入更低的严重性级别中)。
--permit-address-sharing
如果此标志为 true,则在绑定端口时使用 SO_REUSEADDR
。
这就意味着可以同时绑定到 0.0.0.0
和特定的 IP 地址,
并且避免等待内核释放处于 TIME_WAITE
状态的套接字。
--permit-port-sharing
如果为 true,则在绑定端口时将使用 SO_REUSEPORT
,
这允许多个实例在同一地址和端口上进行绑定。
--pod-eviction-timeout duration 默认值:5m0s
在失效的节点上删除 Pods 时为其预留的宽限期。
--profiling 默认值:true
通过位于 host:port/debug/pprof/
的 Web 接口启用性能分析。
--pv-recycler-increment-timeout-nfs int32 默认值:30
NFS 清洗 Pod 在清洗用过的卷时,根据此标志所设置的秒数,为每清洗 1 GiB 数据
增加对应超时时长,作为 activeDeadlineSeconds。
--pv-recycler-minimum-timeout-hostpath int32 默认值:60
对于 HostPath 回收器 Pod,设置其 activeDeadlineSeconds 参数下限。
此参数仅用于开发和测试目的,不适合在多节点集群中使用。
--pv-recycler-minimum-timeout-nfs int32 默认值:300
NFS 回收器 Pod 要使用的 activeDeadlineSeconds 参数下限。
--pv-recycler-pod-template-filepath-hostpath string
对 HostPath 持久卷进行回收利用时,用作模版的 Pod 定义文件所在路径。
此标志仅用于开发和测试目的,不适合多节点集群中使用。
--pv-recycler-pod-template-filepath-nfs string
对 NFS 卷执行回收利用时,用作模版的 Pod 定义文件所在路径。
--pv-recycler-timeout-increment-hostpath int32 默认值:30
HostPath 清洗器 Pod 在清洗对应类型持久卷时,为每 GiB 数据增加此标志所设置的秒数,
作为其 activeDeadlineSeconds 参数。此标志仅用于开发和测试环境,不适合多节点集群环境。
--pvclaimbinder-sync-period duration 默认值:15s
持久卷(PV)和持久卷申领(PVC)对象的同步周期。
--requestheader-allowed-names strings
标志值是客户端证书中的 Common Names 列表。其中所列的名称可以通过
--requestheader-username-headers
所设置的 HTTP 头部来提供用户名。
如果此标志值为空表,则被 --requestheader-client-ca-file
中机构所验证过的所有客户端证书都是允许的。
--requestheader-client-ca-file string
根证书包文件名。在信任通过 --requestheader-username-headers
所指定的任何用户名之前,要使用这里的证书来检查请求中的客户证书。
警告:一般不要依赖对请求所作的鉴权结果。
--requestheader-extra-headers-prefix strings 默认值:"x-remote-extra-"
要插入的请求头部前缀。建议使用 X-Remote-Exra-
。
--requestheader-group-headers strings 默认值:"x-remote-group"
用来检查用户组名的请求头部名称列表。建议使用 X-Remote-Group
。
--requestheader-username-headers strings 默认值:"x-remote-user"
用来检查用户名的请求头部名称列表。建议使用 X-Remote-User
。
--resource-quota-sync-period duration 默认值:5m0s
对系统中配额用量信息进行同步的周期。
--root-ca-file string
如果此标志非空,则在服务账号的令牌 Secret 中会包含此根证书机构。
所指定标志值必须是一个合法的 PEM 编码的 CA 证书包。
--route-reconciliation-period duration 默认值:10s
对云驱动为节点所创建的路由信息进行调解的周期。
--secondary-node-eviction-rate float32 默认值:0.01
当区域不健康,节点失效时,每秒钟从此标志所给的节点个数上删除 Pods。
参见 --unhealthy-zone-threshold
以了解“健康与否”的判定标准。
在只有一个区域的集群中,区域指的是整个集群。如果集群规模小于
--large-cluster-size-threshold
所设置的节点个数时,
此值被隐式地重设为 0。
--secure-port int 默认值:10257
在此端口上提供 HTTPS 身份认证和鉴权操作。若此标志值为 0,则不提供 HTTPS 服务。
--service-account-private-key-file string
包含 PEM 编码的 RSA 或 ECDSA 私钥数据的文件名,这些私钥用来对服务账号令牌签名。
--service-cluster-ip-range string
集群中 Service 对象的 CIDR 范围。要求 --allocate-node-cidrs
标志为 true。
--show-hidden-metrics-for-version string
你希望展示隐藏度量值的上一个版本。只有上一个次版本号有意义,其他值都是不允许的。
字符串格式为 "<major>.<minor>"。例如:"1.16"。
此格式的目的是确保你能够有机会注意到下一个版本隐藏了一些额外的度量值,
而不是在更新版本中某些度量值被彻底删除时措手不及。
--skip-headers
若此标志为 true,则在日志消息中避免写入头部前缀信息。
--skip-log-headers
若此标志为 true,则在写入日志文件时避免写入头部信息。
--stderrthreshold severity 默认值:2
等于或大于此阈值的日志信息会被写入到标准错误输出(stderr)。
--terminated-pod-gc-threshold int32 默认值:12500
在已终止 Pods 垃圾收集器删除已终止 Pods 之前,可以保留的已删除
Pods 的个数上限。若此值小于等于 0,则相当于禁止垃圾回收已终止的 Pods。
--tls-cert-file string
包含 HTTPS 所用的默认 X509 证书的文件。如果有 CA 证书,会被串接在服务器证书之后。
若启用了 HTTPS 服务且 --tls-cert-file
和 --tls-private-key-file
标志未设置,
则为节点的公开地址生成自签名的证书和密钥,并保存到 --cert-dir
所给的目录中。
--tls-cipher-suites strings
供服务器使用的加密包的逗号分隔列表。若忽略此标志,则使用 Go 语言默认的加密包。
可选值包括:TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256、TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256、TLS_RSA_WITH_3DES_EDE_CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHA、TLS_RSA_WITH_AES_128_GCM_SHA256、TLS_RSA_WITH_AES_256_CBC_SHA、TLS_RSA_WITH_AES_256_GCM_SHA384.
不安全的值: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_ECDSA_WITH_RC4_128_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_RSA_WITH_RC4_128_SHA、TLS_RSA_WITH_AES_128_CBC_SHA256、TLS_RSA_WITH_RC4_128_SHA
--tls-min-version string
可支持的最低 TLS 版本。可选值包括:
“VersionTLS10”、“VersionTLS11”、“VersionTLS12”、“VersionTLS13”。
--tls-private-key-file string
包含与 --tls-cert-file
对应的默认 X509 私钥的文件。
--tls-sni-cert-key namedCertKey 默认值:[]
X509 证书和私钥文件路径的耦对。作为可选项,可以添加域名模式的列表,
其中每个域名模式都是可以带通配片段前缀的全限定域名(FQDN)。
域名模式也可以使用 IP 地址字符串,不过只有 API 服务器在所给 IP 地址上
对客户端可见时才可以使用 IP 地址。在未提供域名模式时,从证书中提取域名。
如果有非通配方式的匹配,则优先于通配方式的匹配;显式的域名模式优先于提取的域名。
当存在多个密钥/证书耦对时,可以多次使用 --tls-sni-cert-key
标志。
例如:example.crt,example.key
或 foo.crt,foo.key:\*.foo.com,foo.com
。
--unhealthy-zone-threshold float32 默认值:0.55
仅当给定区域中处于非就绪状态的节点(最少 3 个)的占比高于此值时,
才将该区域视为不健康。
--use-service-account-credentials
当此标志为 true 时,为每个控制器单独使用服务账号凭据。
-v, --v int
日志级别详细程度取值。
--version version[=true]
打印版本信息之后退出。
--vmodule <逗号分隔的 'pattern=N' 配置值>
由逗号分隔的列表,每一项都是 pattern=N 格式,用来执行根据文件过滤的日志行为。
--volume-host-allow-local-loopback 默认值:true
此标志为 false 时,禁止本地回路 IP 地址和 --volume-host-cidr-denylist
中所指定的 CIDR 范围。
--volume-host-cidr-denylist strings
用逗号分隔的一个 CIDR 范围列表,禁止使用这些地址上的卷插件。
11.5 - kube-proxy
简介
Kubernetes 网络代理在每个节点上运行。网络代理反映了每个节点上 Kubernetes API
中定义的服务,并且可以执行简单的 TCP、UDP 和 SCTP 流转发,或者在一组后端进行
循环 TCP、UDP 和 SCTP 转发。
当前可通过 Docker-links-compatible 环境变量找到服务集群 IP 和端口,
这些环境变量指定了服务代理打开的端口。
有一个可选的插件,可以为这些集群 IP 提供集群 DNS。
用户必须使用 apiserver API 创建服务才能配置代理。
kube-proxy [flags]
选项
--add-dir-header
若此标志为 true,则将文件目录添加到日志消息的头部。
--alsologtostderr
将日志输出到文件时也输出到标准错误输出(stderr)。
--azure-container-registry-config string
包含 Azure 容器仓库配置信息的文件的路径。
--bind-address 0.0.0.0 默认值:0.0.0.0
代理服务器要使用的 IP 地址(设置为 '0.0.0.0' 表示要使用所有 IPv4 接口;
设置为 '::' 表示使用所有 IPv6 接口)。
--bind-address-hard-fail
若此标志为 true,kube-proxy 会将无法绑定端口的失败操作视为致命错误并退出。
--boot-id-file string 默认值:"/proc/sys/kernel/random/boot_id"
用来检查 Boot-ID 的文件名,用逗号隔开。
第一个存在的文件会被使用。
--cleanup
如果为 true,清理 iptables 和 ipvs 规则并退出。
--cluster-cidr string
集群中 Pod 的 CIDR 范围。配置后,将从该范围之外发送到服务集群 IP
的流量被伪装,从 Pod 发送到外部 LoadBalancer IP 的流量将被重定向
到相应的集群 IP。
--config string
配置文件的路径。
--config-sync-period duration 默认值:15m0s
来自 apiserver 的配置的刷新频率。必须大于 0。
--conntrack-max-per-core int32 默认值:32768
每个 CPU 核跟踪的最大 NAT 连接数(0 表示保留当前限制并忽略 conntrack-min 设置)。
--conntrack-min int32 默认值:131072
无论 conntrack-max-per-core
多少,要分配的 conntrack
条目的最小数量(将 conntrack-max-per-core
设置为 0 即可
保持当前的限制)。
--conntrack-tcp-timeout-close-wait duration 默认值:1h0m0s
处于 CLOSE_WAIT
状态的 TCP 连接的 NAT 超时。
--conntrack-tcp-timeout-established duration 默认值:24h0m0s
已建立的 TCP 连接的空闲超时(0 保持当前设置)。
--detect-local-mode LocalMode
用于检测本地流量的模式。
--feature-gates <逗号分隔的 'key=True|False' 对’>
一组键=值(key=value)对,描述了 alpha/experimental 的特征。可选项有:
APIListChunking=true|false (BETA - 默认值=true)
APIPriorityAndFairness=true|false (BETA - 默认值=true)
APIResponseCompression=true|false (BETA - 默认值=true)
APIServerIdentity=true|false (ALPHA - 默认值=false)
APIServerTracing=true|false (ALPHA - 默认值=false)
AllAlpha=true|false (ALPHA - 默认值=false)
AllBeta=true|false (BETA - 默认值=false)
AnyVolumeDataSource=true|false (ALPHA - 默认值=false)
AppArmor=true|false (BETA - 默认值=true)
CPUManager=true|false (BETA - 默认值=true)
CPUManagerPolicyOptions=true|false (ALPHA - 默认值=false)
CSIInlineVolume=true|false (BETA - 默认值=true)
CSIMigration=true|false (BETA - 默认值=true)
CSIMigrationAWS=true|false (BETA - 默认值=false)
CSIMigrationAzureDisk=true|false (BETA - 默认值=false)
CSIMigrationAzureFile=true|false (BETA - 默认值=false)
CSIMigrationGCE=true|false (BETA - 默认值=false)
CSIMigrationOpenStack=true|false (BETA - 默认值=true)
CSIMigrationvSphere=true|false (BETA - 默认值=false)
CSIStorageCapacity=true|false (BETA - 默认值=true)
CSIVolumeFSGroupPolicy=true|false (BETA - 默认值=true)
CSIVolumeHealth=true|false (ALPHA - 默认值=false)
CSRDuration=true|false (BETA - 默认值=true)
ConfigurableFSGroupPolicy=true|false (BETA - 默认值=true)
ControllerManagerLeaderMigration=true|false (BETA - 默认值=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
DaemonSetUpdateSurge=true|false (BETA - 默认值=true)
DefaultPodTopologySpread=true|false (BETA - 默认值=true)
DelegateFSGroupToCSIDriver=true|false (ALPHA - 默认值=false)
DevicePlugins=true|false (BETA - 默认值=true)
DisableAcceleratorUsageMetrics=true|false (BETA - 默认值=true)
DisableCloudProviders=true|false (ALPHA - 默认值=false)
DownwardAPIHugePages=true|false (BETA - 默认值=false)
EfficientWatchResumption=true|false (BETA - 默认值=true)
EndpointSliceTerminatingCondition=true|false (BETA - 默认值=true)
EphemeralContainers=true|false (ALPHA - 默认值=false)
ExpandCSIVolumes=true|false (BETA - 默认值=true)
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
ExpandPersistentVolumes=true|false (BETA - 默认值=true)
ExpandedDNSConfig=true|false (ALPHA - 默认值=false)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)
GenericEphemeralVolume=true|false (BETA - 默认值=true)
GracefulNodeShutdown=true|false (BETA - 默认值=true)
HPAContainerMetrics=true|false (ALPHA - 默认值=false)
HPAScaleToZero=true|false (ALPHA - 默认值=false)
IPv6DualStack=true|false (BETA - 默认值=true)
InTreePluginAWSUnregister=true|false (ALPHA - 默认值=false)
InTreePluginAzureDiskUnregister=true|false (ALPHA - 默认值=false)
InTreePluginAzureFileUnregister=true|false (ALPHA - 默认值=false)
InTreePluginGCEUnregister=true|false (ALPHA - 默认值=false)
InTreePluginOpenStackUnregister=true|false (ALPHA - 默认值=false)
InTreePluginvSphereUnregister=true|false (ALPHA - 默认值=false)
IndexedJob=true|false (BETA - 默认值=true)
IngressClassNamespacedParams=true|false (BETA - 默认值=true)
JobTrackingWithFinalizers=true|false (ALPHA - 默认值=false)
KubeletCredentialProviders=true|false (ALPHA - 默认值=false)
KubeletInUserNamespace=true|false (ALPHA - 默认值=false)
KubeletPodResources=true|false (BETA - 默认值=true)
KubeletPodResourcesGetAllocatable=true|false (ALPHA - 默认值=false)
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
LogarithmicScaleDown=true|false (BETA - 默认值=true)
MemoryManager=true|false (BETA - 默认值=true)
MemoryQoS=true|false (ALPHA - 默认值=false)
MixedProtocolLBService=true|false (ALPHA - 默认值=false)
NetworkPolicyEndPort=true|false (BETA - 默认值=true)
NodeSwap=true|false (ALPHA - 默认值=false)
NonPreemptingPriority=true|false (BETA - 默认值=true)
PodAffinityNamespaceSelector=true|false (BETA - 默认值=true)
PodDeletionCost=true|false (BETA - 默认值=true)
PodOverhead=true|false (BETA - 默认值=true)
PodSecurity=true|false (ALPHA - 默认值=false)
PreferNominatedNode=true|false (BETA - 默认值=true)
ProbeTerminationGracePeriod=true|false (BETA - 默认值=false)
ProcMountType=true|false (ALPHA - 默认值=false)
ProxyTerminatingEndpoints=true|false (ALPHA - 默认值=false)
QOSReserved=true|false (ALPHA - 默认值=false)
ReadWriteOncePod=true|false (ALPHA - 默认值=false)
RemainingItemCount=true|false (BETA - 默认值=true)
RemoveSelfLink=true|false (BETA - 默认值=true)
RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
SeccompDefault=true|false (ALPHA - 默认值=false)
ServiceInternalTrafficPolicy=true|false (BETA - 默认值=true)
ServiceLBNodePortControl=true|false (BETA - 默认值=true)
ServiceLoadBalancerClass=true|false (BETA - 默认值=true)
SizeMemoryBackedVolumes=true|false (BETA - 默认值=true)
StatefulSetMinReadySeconds=true|false (ALPHA - 默认值=false)
StorageVersionAPI=true|false (ALPHA - 默认值=false)
StorageVersionHash=true|false (BETA - 默认值=true)
SuspendJob=true|false (BETA - 默认值=true)
TTLAfterFinished=true|false (BETA - 默认值=true)
TopologyAwareHints=true|false (ALPHA - 默认值=false)
TopologyManager=true|false (BETA - 默认值=true)
VolumeCapacityPriority=true|false (ALPHA - 默认值=false)
WinDSR=true|false (ALPHA - 默认值=false)
WinOverlay=true|false (BETA - 默认值=true)
WindowsHostProcessContainers=true|false (ALPHA - 默认值=false)
--healthz-bind-address 0.0.0.0 默认值:0.0.0.0:10256
服务健康状态检查的 IP 地址和端口(设置为 '0.0.0.0:10256' 表示使用所有
IPv4 接口,设置为 '[::]:10256' 表示使用所有 IPv6 接口);
设置为空则禁用。
-h, --help
kube-proxy 操作的帮助命令。
--hostname-override string
如果非空,将使用此字符串而不是实际的主机名作为标识。
--iptables-masquerade-bit int32 默认值:14
在使用纯 iptables 代理时,用来设置 fwmark 空间的 bit,标记需要
SNAT 的数据包。必须在 [0,31] 范围内。
--iptables-min-sync-period duration 默认值:1s
iptables 规则可以随着端点和服务的更改而刷新的最小间隔(例如 '5s'、'1m'、'2h22m')。
--iptables-sync-period duration 默认值:30s
刷新 iptables 规则的最大间隔(例如 '5s'、'1m'、'2h22m')。必须大于 0。
--ipvs-exclude-cidrs strings
逗号分隔的 CIDR 列表,ipvs 代理在清理 IPVS 规则时不会此列表中的地址范围。
--ipvs-min-sync-period duration
ipvs 规则可以随着端点和服务的更改而刷新的最小间隔(例如 '5s'、'1m'、'2h22m')。
--ipvs-scheduler string
代理模式为 ipvs 时所选的 ipvs 调度器类型。
--ipvs-strict-arp
通过将 arp_ignore
设置为 1 并将 arp_announce
设置为 2 启用严格的 ARP。
--ipvs-sync-period duration 默认值:30s
刷新 ipvs 规则的最大间隔(例如 '5s'、'1m'、'2h22m')。必须大于 0。
--ipvs-tcp-timeout duration
空闲 IPVS TCP 连接的超时时间,0 保持连接(例如 '5s'、'1m'、'2h22m')。
--ipvs-tcpfin-timeout duration
收到 FIN 数据包后,IPVS TCP 连接的超时,0 保持当前设置不变。(例如 '5s'、'1m'、'2h22m')。
--ipvs-udp-timeout duration
IPVS UDP 数据包的超时,0 保持当前设置不变。(例如 '5s'、'1m'、'2h22m')。
--kube-api-burst int32 默认值:10
与 kubernetes apiserver 通信的突发数量。
--kube-api-content-type string 默认值:"application/vnd.kubernetes.protobuf"
发送到 apiserver 的请求的内容类型。
--kube-api-qps float32 默认值:5
与 kubernetes apiserver 交互时使用的 QPS。
--kubeconfig string
包含鉴权信息的 kubeconfig 文件的路径(主控节点位置由 master 标志设置)。
--log-backtrace-at <形式为 'file:N' 的字符串> Default: :0
当日志逻辑执行到文件 file 的第 N 行时,输出调用堆栈跟踪。
--log-dir string
若此标志费控,则将日志文件写入到此标志所给的目录下。
--log-file string
若此标志非空,则该字符串作为日志文件名。
--log-file-max-size uint 默认值:1800
定义日志文件可增长到的最大尺寸。单位是兆字节(MB)。
如果此值为 0,则最大文件大小无限制。
--log-flush-frequency duration 默认值:5s
两次日志刷新之间的最大秒数。
--machine-id-file string 默认值:"/etc/machine-id,/var/lib/dbus/machine-id"
用来检查 Machine-ID 的文件列表,用逗号分隔。
使用找到的第一个文件。
--masquerade-all
如果使用纯 iptables 代理,则对通过服务集群 IP 发送的所有流量
进行 SNAT(通常不需要)。
--master string
Kubernetes API 服务器的地址(覆盖 kubeconfig 中的相关值)。
--metrics-bind-address ipport 默认值:127.0.0.1:10249
metrics 服务器要使用的 IP 地址和端口
(设置为 '0.0.0.0:10249' 则使用所有 IPv4 接口,设置为 '[::]:10249' 则使用所有 IPv6 接口)
设置为空则禁用。
--nodeport-addresses strings
一个字符串值,指定用于 NodePort 服务的地址。
值可以是有效的 IP 块(例如 1.2.3.0/24, 1.2.3.4/32)。
默认的空字符串切片([])表示使用所有本地地址。
--one-output
若此标志为 true,则仅将日志写入到其原本的严重性级别之下
(而不是将其写入到所有更低严重性级别中)。
--oom-score-adj int32 默认值:-999
kube-proxy 进程中的 oom-score-adj 值,必须在 [-1000,1000] 范围内。
--profiling
如果为 true,则通过 Web 接口 /debug/pprof
启用性能分析。
--proxy-mode string
使用哪种代理模式:'userspace'(较旧)或 'iptables'(较快)或 'ipvs'。
如果为空,使用最佳可用代理(当前为 iptables)。
如果选择了 iptables 代理(无论是否为显式设置),但系统的内核或
iptables 版本较低,总是会回退到 userspace 代理。
--proxy-port-range port-range
可以用来代理服务流量的主机端口范围(包括'起始端口-结束端口'、
'单个端口'、'起始端口+偏移'几种形式)。
如果未指定或者设置为 0(或 0-0),则随机选择端口。
--show-hidden-metrics-for-version string
要显示隐藏指标的先前版本。
仅先前的次要版本有意义,不允许其他值。
格式为 <major>.<minor> ,例如:'1.16'。
这种格式的目的是确保你有机会注意到下一个发行版是否隐藏了其他指标,
而不是在之后将其永久删除时感到惊讶。
--skip-headers
若此标志为 true,则避免在日志消息中包含头部前缀。
--skip-log-headers
如果此标志为 true,则避免在打开日志文件时使用头部。
--stderrthreshold int 默认值:2
如果日志消息处于或者高于此阈值所设置的级别,则将其输出到标准错误输出(stderr)。
--udp-timeout duration 默认值:250ms
空闲 UDP 连接将保持打开的时长(例如 '250ms','2s')。必须大于 0。
仅适用于 proxy-mode=userspace。
-v, --v int
用来设置日志详细程度的数值。
--version version[=true]
打印版本信息并退出。
--vmodule <逗号分隔的 'pattern=N' 设置’>
用逗号分隔的列表,其中每一项为 'pattern=N' 格式。
用来支持基于文件过滤的日志机制。
--write-config-to string
如果设置,将默认配置信息写入此文件并退出。
11.6 - kube-scheduler
简介
Kubernetes 调度器是一个控制面进程,负责将 Pods 指派到节点上。
调度器基于约束和可用资源为调度队列中每个 Pod 确定其可合法放置的节点。
调度器之后对所有合法的节点进行排序,将 Pod 绑定到一个合适的节点。
在同一个集群中可以使用多个不同的调度器;kube-scheduler 是其参考实现。
参阅调度
以获得关于调度和 kube-scheduler 组件的更多信息。
kube-scheduler [flags]
选项
--add-dir-header
如果为 true,则将文件目录添加到日志消息的头部
--address string 默认值:"0.0.0.0"
已弃用: 要监听 --port 端口的 IP 地址(将其设置为 0.0.0.0 或者 :: 用于监听所有接口和 IP族)。
请参阅 --bind-address。
如果在 --config 中指定了一个配置文件,这个参数将被忽略。
--algorithm-provider string
已弃用: 要使用的调度算法驱动,此标志设置组件配置框架的默认插件。
可选值:ClusterAutoscalerProvider | DefaultProvider
--allow-metric-labels stringToString
默认值: []
这个键值映射表设置 度量标签 所允许设置的值。
其中键的格式是 <MetricName>,<LabelName>。
值的格式是 <allowed_value>,<allowed_value>。
例如:metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'。
--alsologtostderr
日志记录到标准错误以及文件
--authentication-kubeconfig string
指向具有足够权限以创建 tokenaccessreviews.authentication.k8s.io
的
Kubernetes 核心服务器的 kubeconfig 文件。
这是可选的。如果为空,则所有令牌请求均被视为匿名请求,并且不会在集群中查找任何客户端 CA。
--authentication-skip-lookup
如果为 false,则 authentication-kubeconfig 将用于从集群中查找缺少的身份验证配置。
--authentication-token-webhook-cache-ttl duration 默认值:10s
缓存来自 Webhook 令牌身份验证器的响应的持续时间。
--authentication-tolerate-lookup-failure 默认值:true
如果为 true,则无法从集群中查找缺少的身份验证配置是致命的。
请注意,这可能导致身份验证将所有请求视为匿名。
--authorization-always-allow-paths strings 默认值:"/healthz,/readyz,/livez"
在授权过程中跳过的 HTTP 路径列表,即在不联系 'core' kubernetes 服务器的情况下被授权的 HTTP 路径。
--authorization-kubeconfig string
指向具有足够权限以创建 subjectaccessreviews.authorization.k8s.io 的
Kubernetes 核心服务器的 kubeconfig 文件。这是可选的。
如果为空,则所有未被鉴权机制略过的请求都会被禁止。
--authorization-webhook-cache-authorized-ttl duration 默认值:10s
缓存来自 Webhook 授权者的 'authorized' 响应的持续时间。
--authorization-webhook-cache-unauthorized-ttl duration 默认值:10s
缓存来自 Webhook 授权者的 'unauthorized' 响应的持续时间。
--azure-container-registry-config string
包含 Azure 容器仓库配置信息的文件的路径。
--bind-address string 默认值:0.0.0.0
监听 --secure-port 端口的 IP 地址。
集群的其余部分以及 CLI/ Web 客户端必须可以访问关联的接口。
如果为空,将使用所有接口(0.0.0.0 表示使用所有 IPv4 接口,"::" 表示使用所有 IPv6 接口)。
如果为空或未指定地址 (0.0.0.0 或 ::),所有接口将被使用。
--cert-dir string
TLS 证书所在的目录。如果提供了--tls-cert-file 和 --tls private-key-file,
则将忽略此参数。
--client-ca-file string
如果已设置,由 client-ca-file 中的证书机构签名的客户端证书的任何请求都将使用
与客户端证书的 CommonName 对应的身份进行身份验证。
--config string
配置文件的路径。以下标志会覆盖此文件中的值:
--algorithm-provider
--policy-config-file
--policy-configmap
--policy-configmap-namespace
--contention-profiling 默认值: true
已弃用: 如果启用了性能分析,则启用锁竞争分析。
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
--disabled-metrics strings
这个标志提供了一个规避不良指标的选项。你必须提供完整的指标名称才能禁用它。
免责声明:禁用指标的优先级比显示隐藏的指标更高。
--experimental-logging-sanitization
[试验性功能] 当启用此标志时,标记为敏感的字段(密码、密钥、令牌)等不会被日志
输出。
运行时的日志清理操作可能引入相当程度的计算开销,因此不应在生产环境中启用。
--feature-gates <逗号分隔的 'key=True|False' 对>
一组 key=value 对,描述了 alpha/experimental 特征开关。选项包括:
A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
APIListChunking=true|false (BETA - 默认值=true)
APIPriorityAndFairness=true|false (BETA - 默认值=true)
APIResponseCompression=true|false (BETA - 默认值=true)
APIServerIdentity=true|false (ALPHA - 默认值=false)
AllAlpha=true|false (ALPHA - 默认值=false)
AllBeta=true|false (BETA - 默认值=false)
AnyVolumeDataSource=true|false (ALPHA - 默认值=false)
AppArmor=true|false (BETA - 默认值=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)
BoundServiceAccountTokenVolume=true|false (BETA - 默认值=true)
CPUManager=true|false (BETA - 默认值=true)
CSIInlineVolume=true|false (BETA - 默认值=true)
CSIMigration=true|false (BETA - 默认值=true)
CSIMigrationAWS=true|false (BETA - 默认值=false)
CSIMigrationAzureDisk=true|false (BETA - 默认值=false)
CSIMigrationAzureFile=true|false (BETA - 默认值=false)
CSIMigrationGCE=true|false (BETA - 默认值=false)
CSIMigrationOpenStack=true|false (BETA - 默认值=true)
CSIMigrationvSphere=true|false (BETA - 默认值=false)
CSIMigrationvSphereComplete=true|false (BETA - 默认值=false)
CSIServiceAccountToken=true|false (BETA - 默认值=true)
CSIStorageCapacity=true|false (BETA - 默认值=true)
CSIVolumeFSGroupPolicy=true|false (BETA - 默认值=true)
CSIVolumeHealth=true|false (ALPHA - 默认值=false)
ConfigurableFSGroupPolicy=true|false (BETA - 默认值=true)
ControllerManagerLeaderMigration=true|false (ALPHA - 默认值=false)
CronJobControllerV2=true|false (BETA - 默认值=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
DaemonSetUpdateSurge=true|false (ALPHA - 默认值=false)
DefaultPodTopologySpread=true|false (BETA - 默认值=true)
DevicePlugins=true|false (BETA - 默认值=true)
DisableAcceleratorUsageMetrics=true|false (BETA - 默认值=true)
DownwardAPIHugePages=true|false (BETA - 默认值=false)
DynamicKubeletConfig=true|false (BETA - 默认值=true)
EfficientWatchResumption=true|false (BETA - 默认值=true)
EndpointSliceProxying=true|false (BETA - 默认值=true)
EndpointSliceTerminatingCondition=true|false (ALPHA - 默认值=false)
EphemeralContainers=true|false (ALPHA - 默认值=false)
ExpandCSIVolumes=true|false (BETA - 默认值=true)
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
ExpandPersistentVolumes=true|false (BETA - 默认值=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)
GenericEphemeralVolume=true|false (BETA - 默认值=true)
GracefulNodeShutdown=true|false (BETA - 默认值=true)
HPAContainerMetrics=true|false (ALPHA - 默认值=false)
HPAScaleToZero=true|false (ALPHA - 默认值=false)
HugePageStorageMediumSize=true|false (BETA - 默认值=true)
IPv6DualStack=true|false (BETA - 默认值=true)
InTreePluginAWSUnregister=true|false (ALPHA - 默认值=false)
InTreePluginAzureDiskUnregister=true|false (ALPHA - 默认值=false)
InTreePluginAzureFileUnregister=true|false (ALPHA - 默认值=false)
InTreePluginGCEUnregister=true|false (ALPHA - 默认值=false)
InTreePluginOpenStackUnregister=true|false (ALPHA - 默认值=false)
InTreePluginvSphereUnregister=true|false (ALPHA - 默认值=false)
IndexedJob=true|false (ALPHA - 默认值=false)
IngressClassNamespacedParams=true|false (ALPHA - 默认值=false)
KubeletCredentialProviders=true|false (ALPHA - 默认值=false)
KubeletPodResources=true|false (BETA - 默认值=true)
KubeletPodResourcesGetAllocatable=true|false (ALPHA - 默认值=false)
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
LogarithmicScaleDown=true|false (ALPHA - 默认值=false)
MemoryManager=true|false (ALPHA - 默认值=false)
MixedProtocolLBService=true|false (ALPHA - 默认值=false)
NamespaceDefaultLabelName=true|false (BETA - 默认值=true)
NetworkPolicyEndPort=true|false (ALPHA - 默认值=false)
NonPreemptingPriority=true|false (BETA - 默认值=true)
PodAffinityNamespaceSelector=true|false (ALPHA - 默认值=false)
PodDeletionCost=true|false (ALPHA - 默认值=false)
PodOverhead=true|false (BETA - 默认值=true)
PreferNominatedNode=true|false (ALPHA - 默认值=false)
ProbeTerminationGracePeriod=true|false (ALPHA - 默认值=false)
ProcMountType=true|false (ALPHA - 默认值=false)
QOSReserved=true|false (ALPHA - 默认值=false)
RemainingItemCount=true|false (BETA - 默认值=true)
RemoveSelfLink=true|false (BETA - 默认值=true)
RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
ServerSideApply=true|false (BETA - 默认值=true)
ServiceInternalTrafficPolicy=true|false (ALPHA - 默认值=false)
ServiceLBNodePortControl=true|false (ALPHA - 默认值=false)
ServiceLoadBalancerClass=true|false (ALPHA - 默认值=false)
ServiceTopology=true|false (ALPHA - 默认值=false)
SetHostnameAsFQDN=true|false (BETA - 默认值=true)
SizeMemoryBackedVolumes=true|false (ALPHA - 默认值=false)
StorageVersionAPI=true|false (ALPHA - 默认值=false)
StorageVersionHash=true|false (BETA - 默认值=true)
SuspendJob=true|false (ALPHA - 默认值=false)
TTLAfterFinished=true|false (BETA - 默认值=true)
TopologyAwareHints=true|false (ALPHA - 默认值=false)
TopologyManager=true|false (BETA - 默认值=true)
ValidateProxyRedirects=true|false (BETA - 默认值=true)
VolumeCapacityPriority=true|false (ALPHA - 默认值=false)
WarningHeaders=true|false (BETA - 默认值=true)
WinDSR=true|false (ALPHA - 默认值=false)
WinOverlay=true|false (BETA - 默认值=true)
WindowsEndpointSliceProxying=true|false (BETA - 默认值=true)
--hard-pod-affinity-symmetric-weight int32 默认值:1
已弃用: RequiredDuringScheduling 亲和性是不对称的,但是存在与每个
RequiredDuringScheduling 关联性规则相对应的隐式 PreferredDuringScheduling 关联性规则。
--hard-pod-affinity-symmetric-weight
代表隐式 PreferredDuringScheduling
关联性规则的权重。权重必须在 0-100 范围内。
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
-h, --help
kube-scheduler 帮助命令
--http2-max-streams-per-connection int
服务器为客户端提供的 HTTP/2 连接最大限制。零表示使用 Golang 的默认值。
--kube-api-burst int32 默认值:100
已弃用: 与 kubernetes API 通信时使用的突发请求个数限值。
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
--kube-api-content-type string 默认值:"application/vnd.kubernetes.protobuf"
已弃用: 发送到 API 服务器的请求的内容类型。
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
--kube-api-qps float32 默认值:50
已弃用: 与 kubernetes apiserver 通信时要使用的 QPS
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
--kubeconfig string
已弃用: 包含鉴权和主节点位置信息的 kubeconfig 文件的路径。
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
--leader-elect 默认值:true
在执行主循环之前,开始领导者选举并选出领导者。
使用多副本来实现高可用性时,可启用此标志。
--leader-elect-lease-duration duration 默认值:15s
非领导者候选人在观察到领导者更新后将等待直到试图获得领导但未更新的领导者职位的等待时间。
这实际上是领导者在被另一位候选人替代之前可以停止的最大持续时间。
该情况仅在启用了领导者选举的情况下才适用。
--leader-elect-renew-deadline duration 默认值:10s
领导者尝试在停止领导之前更新领导职位的间隔时间。该时间必须小于或等于租赁期限。
仅在启用了领导者选举的情况下才适用。
--leader-elect-resource-lock string 默认值:"leases"
在领导者选举期间用于锁定的资源对象的类型。支持的选项是 `endpoints`、
`configmaps`、`leases`、`endpointleases` 和 `configmapsleases`。
--leader-elect-resource-name string 默认值:"kube-scheduler"
在领导者选举期间用于锁定的资源对象的名称。
--leader-elect-resource-namespace string 默认值:"kube-system"
在领导者选举期间用于锁定的资源对象的命名空间。
--leader-elect-retry-period duration 默认值:2s
客户应在尝试获取和更新领导之间等待的时间。仅在启用了领导者选举的情况下才适用。
--lock-object-name string 默认值:"kube-scheduler"
已弃用: 定义锁对象的名称。将被删除以便使用 --leader-elect-resource-name
。
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
--lock-object-namespace string 默认值:"kube-system"
已弃用: 定义锁对象的命名空间。将被删除以便使用 leader-elect-resource-namespace
。
如果 --config 指定了一个配置文件,那么这个参数将被忽略。
--log-backtrace-at <a string in the form 'file:N'>
默认值: 0
当记录命中行文件 file
的第 N
行时输出堆栈跟踪。
--log-dir string
如果为非空,则在此目录中写入日志文件。
--log-file string
如果为非空,则使用此文件作为日志文件。
--log-file-max-size uint 默认值:1800
定义日志文件可以增长到的最大值。单位为兆字节。
如果值为 0,则最大文件大小为无限制。
--log-flush-frequency duration 默认值:5s
两次日志刷新之间的最大秒数。
--logging-format string 默认值:“text”
设置日志格式。可选格式:“json”,“text”。
采用非默认格式时,以下标识不会生效:
--add-dir-header, --alsologtostderr, --log-backtrace-at,
--log-dir, --log-file, --log-file-max-size,
--logtostderr, --one-output, --skip-headers, --skip-log-headers,
--stderrthreshold, --vmodule, --log-flush-frequency.
非默认选项目前处于 Alpha 阶段,有可能会出现变更且无事先警告。
--logtostderr 默认值:true
日志记录到标准错误输出而不是文件。
--master string
Kubernetes API 服务器的地址(覆盖 kubeconfig 中的任何值)。
--one-output
若此标志为 true,则日志仅写入其自身的严重性级别,而不会写入所有较低严重性级别。
--permit-address-sharing
如果为 true,在绑定端口时将使用 SO_REUSEADDR。
这将允许同时绑定诸如 0.0.0.0 这类通配符 IP和特定 IP,
并且它避免等待内核释放处于 TIME_WAIT 状态的套接字。
默认值: false
--permit-port-sharing
如果此标志为 true,在绑定端口时会使用 SO_REUSEPORT,从而允许不止一个
实例绑定到同一地址和端口。
默认值:false
--policy-config-file string
已弃用:包含调度器策略配置的文件。
当策略 ConfigMap 为提供时,或者 --use-legacy-policy-config=true
时使用此文件。
注意:当此标志与插件配置一起使用时,调度器会失败。
--policy-configmap string
已弃用: 包含调度器策略配置的 ConfigMap 对象的名称。
如果 --use-legacy-policy-config=false,则它必须在调度器初始化之前存在于
系统命名空间中。配置数据必须对应 'data' 映射中键名为 'policy.cfg' 的元素的值。
注意:如果与插件配置一起使用,调度器会失败。
--policy-configmap-namespace string 默认值:"kube-system"
已弃用: 策略 ConfigMap 所在的名字空间。如果未提供或为空,则将使用 kube-system 名字空间。
注意:如果与插件配置一起使用,调度器会失败。
--port int 默认值:10251
已弃用: 在没有身份验证和鉴权的情况下不安全地为 HTTP 服务的端口。
如果为 0,则根本不提供 HTTP。请参见 --secure-port。
如果 --config 指定了一个配置文件,这个参数将被忽略。
--profiling 默认值: true
已弃用: 通过 Web 界面主机启用配置文件:host:port/debug/pprof/
。
如果 --config 指定了一个配置文件,这个参数将被忽略。
--requestheader-allowed-names stringSlice
客户端证书通用名称列表,允许在 --requestheader-username-headers
指定的头部中提供用户名。如果为空,则允许任何由
--requestheader-client-ca-file
中证书机构验证的客户端证书。
--requestheader-client-ca-file string
在信任 --requestheader-username-headers
指定的头部中的用户名之前
用于验证传入请求上的客户端证书的根证书包。
警告:通常不应假定传入请求已经完成鉴权。
--requestheader-extra-headers-prefix strings
默认值: "x-remote-extra-"
要检查请求头部前缀列表。建议使用 X-Remote-Extra-
。
--requestheader-group-headers strings
默认值: "x-remote-group"
用于检查组的请求头部列表。建议使用 X-Remote-Group
。
--requestheader-username-headers strings
默认值: "x-remote-user"
用于检查用户名的请求头部列表。X-Remote-User
很常用。
--scheduler-name string
默认值:"default-scheduler"
已弃用: 调度器名称,用于根据 Pod 的 “spec.schedulerName” 选择此
调度器将处理的 Pod。
如果 --config 指定了一个配置文件,那么这个参数将被忽略
--secure-port int 默认值:10259
通过身份验证和授权为 HTTPS 服务的端口。如果为 0,则根本不提供 HTTPS。
--show-hidden-metrics-for-version string
你希望显式隐藏指标的老版本号。只有较早的此版本号有意义,其它值都是不允许的。
格式为 <主版本>.<此版本>,例如:'1.16'。
此格式的目的是确保你有机会注意到是否下一个发行版本中隐藏了一些额外的指标,
而不是当某些指标在该版本之后被彻底移除时感到震惊。
--skip-headers
如果为 true,日志消息中不再写入头部前缀。
--skip-log-headers
如果为 true,则在打开日志文件时忽略其头部。
--stderrthreshold int 默认值:2
达到或超过此阈值的日志会被写入到标准错误输出。
--tls-cert-file string
包含默认的 HTTPS x509 证书的文件。(CA证书(如果有)在服务器证书之后并置)。
如果启用了 HTTPS 服务,并且未提供 --tls-cert-file
和
--tls-private-key-file
,则会为公共地址生成一个自签名证书和密钥,
并将其保存到 --cert-dir
指定的目录中。
--tls-cipher-suites strings
服务器的密码套件列表,以逗号分隔。如果省略,将使用默认的 Go 密码套件。
优先考虑的值:
TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384.
不安全的值:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA.
--tls-min-version string
支持的最低 TLS 版本。可能的值:VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13
--tls-private-key-file string
包含与 --tls-cert-file 匹配的默认 x509 私钥的文件。
--tls-sni-cert-key string
一对 x509 证书和私钥文件路径,也可以包含由全限定域名构成的域名模式列表作为后缀,
并可能带有前缀的通配符段。域名匹配还允许是 IP 地址,
但是只有当 apiserver 对客户端请求的 IP 地址可见时,才能使用 IP。
如果未提供域名匹配模式,则提取证书名称。
非通配符匹配优先于通配符匹配,显式域名匹配优先于提取而来的名称。
若有多个密钥/证书对,可多次使用 --tls-sni-cert-key
。
例子: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。
--use-legacy-policy-config
已弃用:设置为 true 时,调度程序将忽略策略 ConfigMap 并使用策略配置文件。
注意:当此标志与插件配置一起使用时,调度器会失败。
-v, --v int
设置日志级别详细程度的数字
--version version[=true]
打印版本信息并退出。
--vmodule <逗号分隔的 ‘模式=N’ 配置列表>
以逗号分隔的 ‘模式=N’ 设置列表,用于文件过滤的日志记录。
--write-config-to string
如果已设置,将配置值写入此文件并退出。
11.7 - Kubelet 认证/鉴权
概述
kubelet 的 HTTPS 端点公开了 API,
这些 API 可以访问敏感度不同的数据,
并允许你在节点上和容器内以不同级别的权限执行操作。
本文档介绍了如何对 kubelet 的 HTTPS 端点的访问进行认证和鉴权。
Kubelet 身份认证
默认情况下,未被已配置的其他身份认证方法拒绝的对 kubelet 的 HTTPS 端点的请求会被视为匿名请求,
并被赋予 system:anonymous
用户名和 system:unauthenticated
组。
要禁用匿名访问并向未经身份认证的请求发送 401 Unauthorized
响应,请执行以下操作:
带 --anonymous-auth=false
标志启动 kubelet
要对 kubelet 的 HTTPS 端点启用 X509 客户端证书认证:
带 --client-ca-file
标志启动 kubelet,提供一个 CA 证书包以供验证客户端证书
带 --kubelet-client-certificate
和 --kubelet-client-key
标志启动 apiserver
有关更多详细信息,请参见
apiserver 身份验证文档
要启用 API 持有者令牌(包括服务帐户令牌)以对 kubelet 的 HTTPS 端点进行身份验证,请执行以下操作:
确保在 API 服务器中启用了 authentication.k8s.io/v1beta1
API 组
带 --authentication-token-webhook
和 --kubeconfig
标志启动 kubelet
kubelet 调用已配置的 API 服务器上的 TokenReview
API,以根据持有者令牌确定用户信息
Kubelet 鉴权
任何成功通过身份验证的请求(包括匿名请求)之后都会被鉴权。
默认的鉴权模式为 AlwaysAllow
,它允许所有请求。
细分对 kubelet API 的访问权限可能有多种原因:
启用了匿名身份验证,但是应限制匿名用户调用 kubelet API 的能力
启用了持有者令牌认证,但应限制任意 API 用户(如服务帐户)调用 kubelet API 的能力
启用了客户端证书身份验证,但仅应允许已配置的 CA 签名的某些客户端证书使用 kubelet API
要细分对 kubelet API 的访问权限,请将鉴权委派给 API 服务器:
确保在 API 服务器中启用了 authorization.k8s.io/v1beta1
API 组
带 --authorization-mode=Webhook
和 --kubeconfig
标志启动 kubelet
kubelet 调用已配置的 API 服务器上的 SubjectAccessReview
API,
以确定每个请求是否得到鉴权
kubelet 使用与 apiserver 相同的
请求属性
方法对 API 请求执行鉴权。
请求的动词根据传入请求的 HTTP 动词确定:
HTTP 动词
请求动词
POST
create
GET, HEAD
get
PUT
update
PATCH
patch
DELETE
delete
资源和子资源是根据传入请求的路径确定的:
Kubelet API
资源
子资源
/stats/*
nodes
stats
/metrics/*
nodes
metrics
/logs/*
nodes
log
/spec/*
nodes
spec
其它所有
nodes
proxy
名字空间和 API 组属性始终是空字符串,
资源名称始终是 kubelet 的 Node
API 对象的名称。
在此模式下运行时,请确保传递给 apiserver 的由 --kubelet-client-certificate
和
--kubelet-client-key
标志标识的用户具有以下属性的鉴权:
verb=*, resource=nodes, subresource=proxy
verb=*, resource=nodes, subresource=stats
verb=*, resource=nodes, subresource=log
verb=*, resource=nodes, subresource=spec
verb=*, resource=nodes, subresource=metrics
11.8 - TLS 启动引导
在一个 Kubernetes 集群中,工作节点上的组件(kubelet 和 kube-proxy)需要与
Kubernetes 控制平面组件通信,尤其是 kube-apiserver。
为了确保通信本身是私密的、不被干扰,并且确保集群的每个组件都在与另一个
可信的组件通信,我们强烈建议使用节点上的客户端 TLS 证书。
启动引导这些组件的正常过程,尤其是需要证书来与 kube-apiserver 安全通信的
工作节点,可能会是一个具有挑战性的过程,因为这一过程通常不受 Kubernetes 控制,
需要不少额外工作。
这也使得初始化或者扩缩一个集群的操作变得具有挑战性。
为了简化这一过程,从 1.4 版本开始,Kubernetes 引入了一个证书请求和签名
API 以便简化此过程。该提案可在
这里 看到。
本文档描述节点初始化的过程,如何为 kubelet 配置 TLS 客户端证书启动引导,
以及其背后的工作原理。
初始化过程
当工作节点启动时,kubelet 执行以下操作:
寻找自己的 kubeconfig
文件
检索 API 服务器的 URL 和凭据,通常是来自 kubeconfig
文件中的
TLS 密钥和已签名证书
尝试使用这些凭据来与 API 服务器通信
假定 kube-apiserver 成功地认证了 kubelet 的凭据数据,它会将 kubelet 视为
一个合法的节点并开始将 Pods 分派给该节点。
注意,签名的过程依赖于:
kubeconfig
中包含密钥和本地主机的证书
证书被 kube-apiserver 所信任的一个证书机构(CA)所签名
负责部署和管理集群的人有以下责任:
创建 CA 密钥和证书
将 CA 证书发布到 kube-apiserver 运行所在的控制平面节点上
为每个 kubelet 创建密钥和证书;强烈建议为每个 kubelet 使用独一无二的、
CN 取值与众不同的密钥和证书
使用 CA 密钥对 kubelet 证书签名
将 kubelet 密钥和签名的证书发布到 kubelet 运行所在的特定节点上
本文中描述的 TLS 启动引导过程有意简化甚至完全自动化上述过程,尤其是
第三步之后的操作,因为这些步骤是初始化或者扩缩集群时最常见的操作。
启动引导初始化
在启动引导初始化过程中,会发生以下事情:
kubelet 启动
kubelet 看到自己 没有 对应的 kubeconfig
文件
kubelet 搜索并发现 bootstrap-kubeconfig
文件
kubelet 读取该启动引导文件,从中获得 API 服务器的 URL 和用途有限的
一个“令牌(Token)”
kubelet 建立与 API 服务器的连接,使用上述令牌执行身份认证
kubelet 现在拥有受限制的凭据来创建和取回证书签名请求(CSR)
kubelet 为自己创建一个 CSR,并将其 signerName 设置为 kubernetes.io/kube-apiserver-client-kubelet
CSR 被以如下两种方式之一批复:
如果配置了,kube-controller-manager 会自动批复该 CSR
如果配置了,一个外部进程,或者是人,使用 Kubernetes API 或者使用 kubectl
来批复该 CSR
kubelet 所需要的证书被创建
证书被发放给 kubelet
kubelet 取回该证书
kubelet 创建一个合适的 kubeconfig
,其中包含密钥和已签名的证书
kubelet 开始正常操作
可选地,如果配置了,kubelet 在证书接近于过期时自动请求更新证书
更新的证书被批复并发放;取决于配置,这一过程可能是自动的或者手动完成
本文的其余部分描述配置 TLS 启动引导的必要步骤及其局限性。
配置
要配置 TLS 启动引导及可选的自动批复,你必须配置以下组件的选项:
kube-apiserver
kube-controller-manager
kubelet
集群内的资源:ClusterRoleBinding
以及可能需要的 ClusterRole
此外,你需要有 Kubernetes 证书机构(Certificate Authority,CA)。
证书机构
就像在没有启动引导的情况下,你会需要证书机构(CA)密钥和证书。
这些数据会被用来对 kubelet 证书进行签名。
如前所述,将证书机构密钥和证书发布到控制平面节点是你的责任。
就本文而言,我们假定这些数据被发布到控制平面节点上的
/var/lib/kubernetes/ca.pem
(证书)和
/var/lib/kubernetes/ca-key.pem
(密钥)文件中。
我们将这两个文件称作“Kubernetes CA 证书和密钥”。
所有 Kubernetes 组件(kubelet、kube-apiserver、kube-controller-manager)都使用
这些凭据,并假定这里的密钥和证书都是 PEM 编码的。
kube-apiserver 配置
启用 TLS 启动引导对 kube-apiserver 有若干需求:
能够识别对客户端证书进行签名的 CA
能够对启动引导的 kubelet 执行身份认证,并将其置入 system:bootstrappers
组
能够对启动引导的 kubelet 执行鉴权操作,允许其创建证书签名请求(CSR)
识别客户证书
对于所有客户端证书的认证操作而言,这是很常见的。
如果还没有设置,要为 kube-apiserver 命令添加 --client-ca-file=FILENAME
标志来启用客户端证书认证,在标志中引用一个包含用来签名的证书的证书机构包,
例如:--client-ca-file=/var/lib/kubernetes/ca.pem
。
初始启动引导认证
为了让启动引导的 kubelet 能够连接到 kube-apiserver 并请求证书,
它必须首先在服务器上认证自身身份。你可以使用任何一种能够对 kubelet 执行身份认证的
身份认证组件 。
尽管所有身份认证策略都可以用来对 kubelet 的初始启动凭据来执行认证,
出于容易准备的因素,建议使用如下两个身份认证组件:
启动引导令牌(Bootstrap Token)
令牌认证文件
启动引导令牌是一种对 kubelet 进行身份认证的方法,相对简单且容易管理,
且不需要在启动 kube-apiserver 时设置额外的标志。
无论选择哪种方法,这里的需求是 kubelet 能够被身份认证为某个具有如下权限的用户:
创建和读取 CSR
在启用了自动批复时,能够在请求节点客户端证书时得到自动批复
使用启动引导令牌执行身份认证的 kubelet 会被认证为 system:bootstrappers
组中的用户。这是使用启动引导令牌的一种标准方法。
随着这个功能特性的逐渐成熟,你需要确保令牌绑定到某基于角色的的访问控制(RBAC)
策略上,从而严格限制请求(使用启动引导令牌 )
仅限于客户端申请提供证书。当 RBAC 被配置启用时,可以将令牌限制到某个组,从而
提高灵活性。例如,你可以在准备节点期间禁止某特定启动引导组的访问。
启动引导令牌
启动引导令牌的细节在这里
详述。启动引导令牌在 Kubernetes 集群中存储为 Secret 对象,被发放给各个 kubelet。
你可以在整个集群中使用同一个令牌,也可以为每个节点发放单独的令牌。
这一过程有两个方面:
基于令牌 ID、机密数据和范畴信息创建 Kubernetes Secret
将令牌发放给 kubelet
从 kubelet 的角度,所有令牌看起来都很像,没有特别的含义。
从 kube-apiserver 服务器的角度,启动引导令牌是很特殊的。
根据其 type
、namespace
和 name
,kube-apiserver 能够将认作特殊的令牌,
并授予携带该令牌的任何人特殊的启动引导权限,换言之,将其视为
system:bootstrappers
组的成员。这就满足了 TLS 启动引导的基本需求。
关于创建 Secret 的进一步细节可访问这里 。
如果你希望使用启动引导令牌,你必须在 kube-apiserver 上使用下面的标志启用之:
--enable-bootstrap-token-auth=true
令牌认证文件
kube-apiserver 能够将令牌视作身份认证依据。
这些令牌可以是任意数据,但必须表示为基于某安全的随机数生成器而得到的
至少 128 位混沌数据。这里的随机数生成器可以是现代 Linux 系统上的
/dev/urandom
。生成令牌的方式有很多种。例如:
head -c 16 /dev/urandom | od -An -t x | tr -d ' '
上面的命令会生成类似于 02b50b05283e98dd0fd71db496ef01e8
这样的令牌。
令牌文件看起来是下面的例子这样,其中前面三个值可以是任何值,用引号括起来
的组名称则只能用例子中给的值。
02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:bootstrappers"
向 kube-apiserver 添加 --token-auth-file=FILENAME
标志(或许这要对 systemd
的单元文件作修改)以启用令牌文件。参见
这里
的文档以了解进一步的细节。
授权 kubelet 创建 CSR
现在启动引导节点被身份认证为 system:bootstrapping
组的成员,它需要被 授权
创建证书签名请求(CSR)并在证书被签名之后将其取回。
幸运的是,Kubernetes 提供了一个 ClusterRole
,其中精确地封装了这些许可,
system:node-bootstrapper
。
为了实现这一点,你只需要创建 ClusterRoleBinding
,将 system:bootstrappers
组绑定到集群角色 system:node-bootstrapper
。
# 允许启动引导节点创建 CSR
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRoleBinding
metadata :
name : create-csrs-for-bootstrapping
subjects :
- kind : Group
name : system:bootstrappers
apiGroup : rbac.authorization.k8s.io
roleRef :
kind : ClusterRole
name : system:node-bootstrapper
apiGroup : rbac.authorization.k8s.io
kube-controller-manager 配置
API 服务器从 kubelet 收到证书请求并对这些请求执行身份认证,但真正负责发放
签名证书的是控制器管理器。
控制器管理器通过一个证书发放的控制回路来执行此操作。该操作的执行方式是使用磁盘上
的文件用 cfssl 本地签名组件
来完成。目前,所发放的所有证书都有一年的有效期,并设定了默认的一组密钥用法。
为了让控制器管理器对证书签名,它需要:
能够访问你之前所创建并分发的“Kubernetes CA 密钥和证书”
启用 CSR 签名
访问密钥和证书
如前所述,你需要创建一个 Kubernetes CA 密钥和证书,并将其发布到控制平面节点。
这些数据会被控制器管理器来对 kubelet 证书进行签名。
由于这些被签名的证书反过来会被 kubelet 用来在 kube-apiserver 执行普通的
kubelet 身份认证,很重要的一点是为控制器管理器所提供的 CA 也被 kube-apiserver
信任用来执行身份认证。CA 密钥和证书是通过 kube-apiserver 的标志
--client-ca-file=FILENAME
(例如,--client-ca-file=/var/lib/kubernetes/ca.pem
),
来设定的,正如 kube-apiserver 配置节所述。
要将 Kubernetes CA 密钥和证书提供给 kube-controller-manager,可使用以下标志:
--cluster-signing-cert-file= "/etc/path/to/kubernetes/ca/ca.crt" --cluster-signing-key-file= "/etc/path/to/kubernetes/ca/ca.key"
例如:
--cluster-signing-cert-file= "/var/lib/kubernetes/ca.pem" --cluster-signing-key-file= "/var/lib/kubernetes/ca-key.pem"
所签名的证书的合法期限可以通过下面的标志来配置:
--cluster-signing-duration
批复
为了对 CSR 进行批复,你需要告诉控制器管理器批复这些 CSR 是可接受的。
这是通过将 RBAC 访问权限授予正确的组来实现的。
许可权限有两组:
nodeclient
:如果节点在为节点创建新的证书,则该节点还没有证书。该节点
使用前文所列的令牌之一来执行身份认证,因此是组 system:bootstrappers
组
的成员。
selfnodeclient
:如果节点在对证书执行续期操作,则该节点已经拥有一个证书。
节点持续使用现有的证书将自己认证为 system:nodes
组的成员。
要允许 kubelet 请求并接收新的证书,可以创建一个 ClusterRoleBinding
将启动
引导节点所处的组 system:bootstrappers
绑定到为其赋予访问权限的
ClusterRole
system:certificates.k8s.io:certificatesigningrequests:nodeclient
:
# 批复 "system:bootstrappers" 组的所有 CSR
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRoleBinding
metadata :
name : auto-approve-csrs-for-group
subjects :
- kind : Group
name : system:bootstrappers
apiGroup : rbac.authorization.k8s.io
roleRef :
kind : ClusterRole
name : system:certificates.k8s.io:certificatesigningrequests:nodeclient
apiGroup : rbac.authorization.k8s.io
要允许 kubelet 对其客户端证书执行续期操作,可以创建一个 ClusterRoleBinding
将正常工作的节点所处的组 system:nodes
绑定到为其授予访问许可的 ClusterRole
system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
:
# 批复 "system:nodes" 组的 CSR 续约请求
apiVersion : rbac.authorization.k8s.io/v1
kind : ClusterRoleBinding
metadata :
name : auto-approve-renewals-for-nodes
subjects :
- kind : Group
name : system:nodes
apiGroup : rbac.authorization.k8s.io
roleRef :
kind : ClusterRole
name : system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
apiGroup : rbac.authorization.k8s.io
作为 kube-controller-manager
的一部分的 csrapproving
控制器是自动被启用的。
该控制器使用 SubjectAccessReview
API
来确定是否某给定用户被授权请求 CSR,之后基于鉴权结果执行批复操作。
为了避免与其它批复组件发生冲突,内置的批复组件不会显式地拒绝任何 CSRs。
该组件仅是忽略未被授权的请求。
控制器也会作为垃圾收集的一部分清除已过期的证书。
kubelet 配置
最后,当控制平面节点被正确配置并且所有必要的身份认证和鉴权机制都就绪时,
我们可以配置 kubelet。
kubelet 需要以下配置来执行启动引导:
一个用来存储所生成的密钥和证书的路径(可选,可以使用默认配置)
一个用来指向尚不存在的 kubeconfig
文件的路径;kubelet 会将启动引导
配置文件放到这个位置
一个指向启动引导 kubeconfig
文件的路径,用来提供 API 服务器的 URL
和启动引导凭据,例如,启动引导令牌
可选的:轮换证书的指令
启动引导 kubeconfig
文件应该放在一个 kubelet 可访问的路径下,例如
/var/lib/kubelet/bootstrap-kubeconfig
。
其格式与普通的 kubeconfig
文件完全相同。实例文件可能看起来像这样:
apiVersion : v1
kind : Config
clusters :
- cluster :
certificate-authority : /var/lib/kubernetes/ca.pem
server : https://my.server.example.com:6443
name : bootstrap
contexts :
- context :
cluster : bootstrap
user : kubelet-bootstrap
name : bootstrap
current-context : bootstrap
preferences : {}
users :
- name : kubelet-bootstrap
user :
token : 07401b.f395accd246ae52d
需要额外注意的一些因素有:
certificate-authority
:指向 CA 文件的路径,用来对 kube-apiserver 所出示
的服务器证书进行验证
server
: 用来访问 kube-apiserver 的 URL
token
:要使用的令牌
令牌的格式并不重要,只要它与 kube-apiserver 的期望匹配即可。
在上面的例子中,我们使用的是启动引导令牌。
如前所述,任何合法的身份认证方法都可以使用,不限于令牌。
因为启动引导 kubeconfig
文件是一个标准的 kubeconfig
文件,你可以使用
kubectl
来生成该文件。要生成上面的示例文件:
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-cluster bootstrap --server='https://my.server.example.com:6443' --certificate-authority=/var/lib/kubernetes/ca.pem
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-credentials kubelet-bootstrap --token=07401b.f395accd246ae52d
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-context bootstrap --user=kubelet-bootstrap --cluster=bootstrap
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig use-context bootstrap
要指示 kubelet 使用启动引导 kubeconfig
文件,可以使用下面的 kubelet 标志:
--bootstrap-kubeconfig="/var/lib/kubelet/bootstrap-kubeconfig" --kubeconfig="/var/lib/kubelet/kubeconfig"
在启动 kubelet 时,如果 --kubeconfig
标志所指定的文件并不存在,会使用通过标志
--bootstrap-kubeconfig
所指定的启动引导 kubeconfig 配置来向 API 服务器请求
客户端证书。在证书请求被批复并被 kubelet 收回时,一个引用所生成的密钥和所获得
证书的 kubeconfig 文件会被写入到通过 --kubeconfig
所指定的文件路径下。
证书和密钥文件会被放到 --cert-dir
所指定的目录中。
客户和服务证书
前文所述的内容都与 kubelet 客户端 证书相关,尤其是 kubelet 用来向
kube-apiserver 认证自身身份的证书。
kubelet 也可以使用 服务(Serving) 证书。kubelet 自身向外提供一个
HTTPS 末端,包含若干功能特性。要保证这些末端的安全性,kubelet 可以执行以下操作
之一:
使用通过 --tls-private-key-file
和 --tls-cert-file
所设置的密钥和证书
如果没有提供密钥和证书,则创建自签名的密钥和证书
通过 CSR API 从集群服务器请求服务证书
TLS 启动引导所提供的客户端证书默认被签名为仅用于 client auth
(客户端认证),
因此不能作为提供服务的证书,或者 server auth
。
不过,你可以启用服务器证书,至少可以部分地通过证书轮换来实现这点。
证书轮换
Kubernetes v1.8 和更高版本的 kubelet 实现了对客户端证书与/或服务证书进行轮换
这一 Beta 特性。这一特性通过 kubelet 对应的 RotateKubeletClientCertificate
和
RotateKubeletServerCertificate
特性门控标志来控制,并且是默认启用的。
RotateKubeletClientCertificate
会导致 kubelet 在其现有凭据即将过期时通过
创建新的 CSR 来轮换其客户端证书。要启用此功能特性,可将下面的标志传递给
kubelet:
--rotate-certificates
RotateKubeletServerCertificate
会让 kubelet 在启动引导其客户端凭据之后请求
一个服务证书 且 对该服务证书执行轮换操作。要启用此功能特性,将下面的标志
传递给 kubelet:
--rotate-server-certificates
说明:
Kubernetes 核心中所实现的 CSR 批复控制器出于
安全原因
并不会自动批复节点的 服务 证书。
要使用 RotateKubeletServerCertificate
功能特性,集群运维人员需要运行一个
定制的控制器或者手动批复服务证书的请求。
对 kubelet 服务证书的批复过程因集群部署而异,通常应该仅批复如下 CSR:
由节点发出的请求(确保 spec.username
字段形式为 system:node:<nodeName>
且 spec.groups
包含 system:nodes
)
请求中包含服务证书用法(确保 spec.usages
中包含 server auth
,可选地也可
包含 digital signature
和 key encipherment
,且不包含其它用法)
仅包含隶属于请求节点的 IP 和 DNS 的 subjectAltNames
,没有 URI 和 Email
形式的 subjectAltNames
(解析 spec.request
中的 x509 证书签名请求可以
检查 subjectAltNames
)
其它身份认证组件
本文所描述的所有 TLS 启动引导内容都与 kubelet 相关。不过,其它组件也可能需要
直接与 kube-apiserver 直接通信。容易想到的是 kube-proxy,同样隶属于
Kubernetes 的控制面并且运行在所有节点之上,不过也可能包含一些其它负责
监控或者联网的组件。
与 kubelet 类似,这些其它组件也需要一种向 kube-apiserver 认证身份的方法。
你可以用几种方法来生成这类凭据:
较老的方式:和 kubelet 在 TLS 启动引导之前所做的一样,用类似的方式
创建和分发证书
DaemonSet:由于 kubelet 自身被加载到所有节点之上,并且有足够能力来启动基本服务,
你可以运行将 kube-proxy 和其它特定节点的服务作为 kube-system
名字空间中的
DaemonSet 来执行,而不是独立的进程。由于 DaemonSet 位于集群内部,你可以为其
指派一个合适的服务账户,使之具有适当的访问权限来完成其使命。这也许是配置此类
服务的最简单的方法。
kubectl 批复
CSRs 可以在控制器管理其内置的批复工作流之外被批复。
签名控制器并不会立即对所有证书请求执行签名操作。相反,它会等待这些请求被某
具有适当特权的用户标记为 “Approved(已批准)”状态。
这一流程有意允许由外部批复控制器来自动执行的批复,或者由控制器管理器内置的
批复控制器来自动批复。
不过,集群管理员也可以使用 kubectl
来手动批准证书请求。
管理员可以通过 kubectl get csr
来列举所有的 CSR,使用
kubectl descsribe csr <name>
来描述某个 CSR 的细节。
管理员可以使用 kubectl certificate approve <name
来批准某 CSR,或者
kubectl certificate deny <name>
来拒绝某 CSR。
12 - 配置 API
12.1 - Client Authentication (v1beta1)
Resource Types
ExecCredential
ExecCredential is used by exec-based plugins to communicate credentials to
HTTP transports.
Field Description
apiVersion
stringclient.authentication.k8s.io/v1beta1
kind
stringExecCredential
spec
[Required]
ExecCredentialSpec
Spec holds information passed to the plugin by the transport.
status
ExecCredentialStatus
Status is filled in by the plugin and holds the credentials that the transport
should use to contact the API.
Cluster
Appears in:
Cluster contains information to allow an exec plugin to communicate
with the kubernetes cluster being authenticated to.
To ensure that this struct contains everything someone would need to communicate
with a kubernetes cluster (just like they would via a kubeconfig), the fields
should shadow "k8s.io/client-go/tools/clientcmd/api/v1".Cluster, with the exception
of CertificateAuthority, since CA data will always be passed to the plugin as bytes.
Field Description
server
[Required]
string
Server is the address of the kubernetes cluster (https://hostname:port).
tls-server-name
string
TLSServerName is passed to the server for SNI and is used in the client to
check server certificates against. If ServerName is empty, the hostname
used to contact the server is used.
insecure-skip-tls-verify
bool
InsecureSkipTLSVerify skips the validity check for the server's certificate.
This will make your HTTPS connections insecure.
certificate-authority-data
[]byte
CAData contains PEM-encoded certificate authority certificates.
If empty, system roots should be used.
proxy-url
string
ProxyURL is the URL to the proxy to be used for all requests to this
cluster.
config
k8s.io/apimachinery/pkg/runtime.RawExtension
Config holds additional config data that is specific to the exec
plugin with regards to the cluster being authenticated to.
This data is sourced from the clientcmd Cluster object's
extensions[client.authentication.k8s.io/exec] field:
clusters:
name: my-cluster
cluster:
...
extensions:
name: client.authentication.k8s.io/exec # reserved extension name for per cluster exec config
extension:
audience: 06e3fbd18de8 # arbitrary config
In some environments, the user config may be exactly the same across many clusters
(i.e. call this exec plugin) minus some details that are specific to each cluster
such as the audience. This field allows the per cluster config to be directly
specified with the cluster info. Using this field to store secret data is not
recommended as one of the prime benefits of exec plugins is that no secrets need
to be stored directly in the kubeconfig.
ExecCredentialSpec
Appears in:
ExecCredentialSpec holds request and runtime specific information provided by
the transport.
Field Description
cluster
Cluster
Cluster contains information to allow an exec plugin to communicate with the
kubernetes cluster being authenticated to. Note that Cluster is non-nil only
when provideClusterInfo is set to true in the exec provider config (i.e.,
ExecConfig.ProvideClusterInfo).
ExecCredentialStatus
Appears in:
ExecCredentialStatus holds credentials for the transport to use.
Token and ClientKeyData are sensitive fields. This data should only be
transmitted in-memory between client and exec plugin process. Exec plugin
itself should at least be protected via file permissions.
Field Description
expirationTimestamp
meta/v1.Time
ExpirationTimestamp indicates a time when the provided credentials expire.
token
[Required]
string
Token is a bearer token used by the client for request authentication.
clientCertificateData
[Required]
string
PEM-encoded client TLS certificates (including intermediates, if any).
clientKeyData
[Required]
string
PEM-encoded private key for the above certificate.
12.2 - kube-apiserver Audit 配置 (v1)
资源类型
Event
出现在:
Event 结构包含可出现在 API 审计日志中的所有信息。
字段 描述
apiVersion
stringaudit.k8s.io/v1
kind
stringEvent
level
[必需]
Level
生成事件所对应的审计级别。
auditID
[必需]
k8s.io/apimachinery/pkg/types.UID
为每个请求所生成的唯一审计 ID。
stage
[必需]
Stage
生成此事件时请求的处理阶段。
requestURI
[必需]
string
requestURI 是客户端发送到服务器端的请求 URI。
verb
[必需]
string
verb 是与请求对应的 Kubernetes 动词。对于非资源请求,此字段为 HTTP 方法的小写形式。
user
[必需]
authentication/v1.UserInfo
关于认证用户的信息。
impersonatedUser
authentication/v1.UserInfo
关于所伪装(impersonated)的用户的信息。
sourceIPs
[]string
发起请求和中间代理的源 IP 地址。
userAgent
string
userAgent 中记录客户端所报告的用户代理(User Agent)字符串。
注意 userAgent 信息是由客户端提供的,一定不要信任。
objectRef
ObjectReference
此请求所指向的对象引用。对于 List 类型的请求或者非资源请求,此字段可忽略。
responseStatus
meta/v1.Status
响应的状态,当 responseObject 不是 Status 类型时被赋值。
对于成功的请求,此字段仅包含 code 和 statusSuccess。
对于非 Status 类型的错误响应,此字段会被自动赋值为出错信息。
requestObject
k8s.io/apimachinery/pkg/runtime.Unknown
来自请求的 API 对象,以 JSON 格式呈现。requestObject 在请求中按原样记录
(可能会采用 JSON 重新编码),之后会进入版本转换、默认值填充、准入控制以及
配置信息合并等阶段。此对象为外部版本化的对象类型,甚至其自身可能并不是一个
合法的对象。对于非资源请求,此字段被忽略。
只有当审计级别为 Request 或更高的时候才会记录。
responseObject
k8s.io/apimachinery/pkg/runtime.Unknown
响应中包含的 API 对象,以 JSON 格式呈现。requestObject 是在被转换为外部类型
并序列化为 JSON 格式之后才被记录的。
对于非资源请求,此字段会被忽略。
只有审计级别为 Response 时才会记录。
requestReceivedTimestamp
meta/v1.MicroTime
请求到达 API 服务器时的时间。
stageTimestamp
meta/v1.MicroTime
请求到达当前审计阶段时的时间。
annotations
map[string]string
annotations 是一个无结构的键-值映射,其中保存的是一个审计事件。
该事件可以由请求处理链路上的插件来设置,包括身份认证插件、鉴权插件以及
准入控制插件等。
注意这些注解是针对审计事件本身的,与所提交的对象中的 metadata.annotations
之间不存在对应关系。
映射中的键名应该唯一性地标识生成该事件的组件,从而避免名字上的冲突
(例如 podsecuritypolicy.admission.k8s.io/policy)。
映射中的键值应该比较简洁。
当审计级别为 Metadata 时会包含 annotations 字段。
EventList
EventList 是审计事件(Event)的列表。
字段 描述
apiVersion
stringaudit.k8s.io/v1
kind
stringEventList
metadata
meta/v1.ListMeta
列表结构元数据
items
[必需]
[]Event
事件对象列表
Policy
出现在:
Policy 定义的是审计日志的配置以及不同类型请求的日志记录规则。
字段 描述
apiVersion
stringaudit.k8s.io/v1
kind
stringPolicy
metadata
meta/v1.ObjectMeta
包含 metadata
字段是为了便于与 API 基础设施之间实现互操作。
参考 Kubernetes API 文档了解 metadata
字段的详细信息。
rules
[必需]
[]PolicyRule
字段 rules 设置请求要被记录的审计级别(level)。
每个请求可能会与多条规则相匹配;发生这种状况时遵从第一条匹配规则。
默认的审计级别是 None,不过可以在列表的末尾使用一条全抓(catch-all)规则
重载其设置。
列表中的规则(PolicyRule)是严格有序的。
omitStages
[]Stage
字段 omitStages 是一个阶段(Stage)列表,其中包含无须生成事件的阶段。
注意这一选项也可以通过每条规则来设置。
审计组件最终会忽略出现在 omitStages 中阶段,也会忽略规则中的阶段。
PolicyList
PolicyList 是由审计策略(Policy)组成的列表。
字段 描述
apiVersion
stringaudit.k8s.io/v1
kind
stringPolicyList
metadata
meta/v1.ListMeta
列表结构元数据。
items
[必需]
[]Policy
策略(Policy)对象列表。
GroupResources
出现在:
GroupResources 代表的是某 API 组中的资源类别。
字段 描述
group
string
字段 group 给出包含资源的 API 组的名称。
空字符串代表 core
API 组。
resources
[]string
如果存在通配符,则合法性检查逻辑会确保 resources 中的条目不会彼此重叠。
空的列表意味着规则适用于该 API 组中的所有资源及其子资源。
resourceNames
[]string
字段 resourceNames 是策略将匹配的资源实例名称列表。
使用此字段时,resources
必须指定。
空的 resourceNames 列表意味着资源的所有实例都会匹配到此策略。
Level
string
数据类型的别名。
出现在:
Level 定义的是审计过程中在日志内记录的信息量。
ObjectReference
出现在:
ObjectReference 包含的是用来检查或修改所引用对象时将需要的全部信息。
字段 描述
resource
string
资源类别。
namespace
string
资源对象所在名字空间。
name
string
资源对象名称。
uid
k8s.io/apimachinery/pkg/types.UID
资源对象的唯一标识(UID)。
apiGroup
string
字段 apiGroup 给出包含所引用对象的 API 组的名称。
空字符串代表 core
API 组。
apiVersion
string
字段 apiVersion 是包含所引用对象的 API 组的版本。
resourceVersion
string
资源对象自身的版本值。
subresource
string
子资源的类别。
PolicyRule
出现在:
PolicyRule 包含一个映射,基于元数据将请求映射到某审计级别。
请求必须与每个字段所定义的规则都匹配(即 rules 的交集)才被视为匹配。
字段 描述
level
[必需]
Level
与此规则匹配的请求所对应的日志记录级别(Level)。
users
[]string
根据身份认证所确定的用户名的列表,给出此规则所适用的用户。
空列表意味着适用于所有用户。
userGroups
[]string
此规则所适用的用户组的列表。如果用户是所列用户组中任一用户组的成员,则视为匹配。
空列表意味着适用于所有用户组。
verbs
[]string
此规则所适用的动词(verb)列表。
空列表意味着适用于所有动词。
resources
[]GroupResources
此规则所适用的资源类别列表。
空列表意味着适用于 API 组中的所有资源类别。
namespaces
[]string
此规则所适用的名字空间列表。
空字符串("")意味着适用于非名字空间作用域的资源。
空列表意味着适用于所有名字空间。
nonResourceURLs
[]string
字段 nonResourceURLs 给出一组需要被审计的 URL 路径。
允许使用 ∗,但只能作为路径中最后一个完整分段。
例如:
"/metrics" - 记录对 API 服务器度量值(metrics)的所有请求;
"/healthz∗" - 记录所有健康检查请求。
omitStages
[]Stage
字段 omitStages 是一个阶段(Stage)列表,针对所列的阶段服务器不会生成审计事件。
注意这一选项也可以在策略(Policy)级别指定。服务器审计组件会忽略
omitStages 中给出的阶段,也会忽略策略中给出的阶段。
空列表意味着不对阶段作任何限制。
Stage
string
数据类型的别名。
出现在:
Stage 定义在请求处理过程中可以生成审计事件的阶段。
12.3 - kube-apiserver 加密配置 (v1)
包 v1 是 API 的 v1 版本。
资源类型
EncryptionConfiguration
EncryptionConfiguration 为加密驱动保存完整的配置信息。
字段 描述
apiVersion
stringapiserver.config.k8s.io/v1
kind
stringEncryptionConfiguration
resources
[必需]
[]ResourceConfiguration
resources
是一个包含资源及其对应的加密驱动的列表。
AESConfiguration
出现在:
AESConfiguration 包含 AES 转换器的 API 配置信息。
字段 描述
keys
[必需]
[]Key
keys
是一组用于创建 AES 转换器的秘钥。
对于 AES-CBC,每个秘钥必须是 32 字节长;对于 AES-GCM,每个秘钥可以是 16、24、32 字节长。
IdentityConfiguration
出现在:
IdentityConfiguration 是一个空的结构,用来支持在驱动配置中支持标识转换器。
KMSConfiguration
出现在:
KMSConfiguration 包含基于 KMS 的封套转换器的名称、缓存大小以及配置文件路径信息。
字段 描述
name
[必需]
string
name
是要使用的 KMS 插件名称。
cachesize
int32
cachesize
是可在内存中缓存的 Secret 数量上限。默认值是 1000。将此字段设置为负值会禁用缓存。
endpoint
[必需]
string
endpoint
是 gRPC 服务器的监听地址,例如 "unix:///var/run/kms-provider.sock"。
timeout
meta/v1.Duration
对 KMS 插件执行 gRPC 调用的超时时长(例如,'5s')。默认值为 3 秒。
Key
出现在:
Key 中包含为某转换器所提供的键名和对应的私密数据。
字段 描述
name
[必需]
string
name
是在向磁盘中存储数据时使用的键名。
secret
[必需]
string
secret
是实际的秘钥,用 base64 编码。
ProviderConfiguration
出现在:
ProviderConfiguration 为加密驱动存储配置信息。
ResourceConfiguration
出现在:
ResourceConfiguration 中保存资源配置。
字段 描述
resources
[必需]
[]string
resources
是必需要加密的 Kubernetes 资源的列表。
providers
[必需]
[]ProviderConfiguration
providers
是一个转换器列表,用来将资源写入到磁盘或从磁盘上读出。
例如:'aesgcm'、'aescbc'、'secretbox'、'identity'。
SecretboxConfiguration
出现在:
SecretboxConfiguration 包含用于某 Secretbox 转换器的 API 配置。
字段 描述
keys
[必需]
[]Key
keys
是一个秘钥列表,用来创建 Secretbox 转换器。每个秘钥必须是 32 字节长。
12.4 - kube-apiserver 配置 (v1)
v1 包中包含 API 的 v1 版本。
资源类型
AdmissionConfiguration
AdmissionConfiguration 为准入控制器提供版本化的配置。
AdmissionPluginConfiguration
出现在:
AdmissionPluginConfiguration 为某个插件提供配置信息。
字段 描述
name
[必需]
string
name
是准入控制器的名称。它必须与所注册的准入插件名称匹配。
path
string
path
是指向包含插件配置信息的配置文件的路径。
configuration
k8s.io/apimachinery/pkg/runtime.Unknown
configuration
是一个内嵌的配置对象,用来保存插件的配置信息。
如果存在,则使用这里的配置信息而不是指向配置文件的路径。
12.5 - kube-apiserver 配置 (v1alpha1)
包 v1alpha1 包含 API 的 v1alpha1 版本。
资源类型
AdmissionConfiguration
AdmissionConfiguration 为准入控制器提供版本化的配置信息。
EgressSelectorConfiguration
EgressSelectorConfiguration 为 Egress 选择算符客户端提供版本化的配置选项。
字段 描述
apiVersion
stringapiserver.k8s.io/v1alpha1
kind
stringEgressSelectorConfiguration
egressSelections
[必需]
[]EgressSelection
connectionServices
包含一组 Egress 选择算符客户端配置选项。
TracingConfiguration
TracingConfiguration 为跟踪客户端提供版本化的配置信息。
字段 描述
apiVersion
stringapiserver.k8s.io/v1alpha1
kind
stringTracingConfiguration
endpoint
string
在控制面节点上运行的采集器的端点。
API 服务器在向采集器发送数据时将 egressType
设置为 ControlPlane。
这里的语法定义在 https://github.com/grpc/grpc/blob/master/doc/naming.md。
默认值为 otlpgrpc 的默认值,即 localhost:4317
这一连接是不安全的,且不支持 TLS。
samplingRatePerMillion
int32
samplingRatePerMillion
设置每一百万个数据点中要采样的样本个数。默认值为 0。
AdmissionPluginConfiguration
出现在:
AdmissionPluginConfiguration 为某个插件提供配置信息。
字段 描述
name
[必需]
string
name
是准入控制器的名称。此名称必须与所注册的准入插件名称匹配。
path
string
path
为指向包含插件配置数据的配置文件的路径。
configuration
k8s.io/apimachinery/pkg/runtime.Unknown
configuration
是一个嵌入的配置对象,用作插件的配置数据来源。
如果设置了此字段,则使用此字段而不是指向配置文件的路径。
Connection
出现在:
Connection 提供某个 Egress 选择客户端的配置信息。
字段 描述
proxyProtocol
[必需]
ProtocolType
proxyProtocol
是客户端连接到 konnectivity 服务器所使用的协议。
transport
Transport
transport
定义的是传输层的配置。我们使用这个配置来联系 konnectivity 服务器。
当 proxyProtocol
是 HTTPConnect 或 GRPC 时需要设置此字段。
EgressSelection
出现在:
EgressSelection 为某个 Egress 选择客户端提供配置信息。
字段 描述
name
[必需]
string
name
是 Egress 选择器的名称。当前支持的取值有 "controlplane",
"master","etcd" 和 "cluster"。
"master" Egress 选择器已被弃用,推荐使用 "controlplane"。
connection
[必需]
Connection
connection
是用来配置 Egress 选择器的配置信息。
ProtocolType
(string
类型的别名)
出现在:
ProtocolType 是 connection.protocolType
的合法值集合。
TCPTransport
出现在:
TCPTransport 提供使用 TCP 连接 konnectivity 服务器时需要的信息。
字段 描述
url
[必需]
string
url
是要连接的 konnectivity 服务器的位置。例如 "https://127.0.0.1:8131"。
tlsConfig
TLSConfig
tlsConfig
是使用 TLS 来连接 konnectivity 服务器时需要的信息。
TLSConfig
出现在:
TLSConfig 为连接 konnectivity 服务器提供身份认证信息。仅用于 TCPTransport。
字段 描述
caBundle
string
caBundle
是指向用来确定与 konnectivity 服务器间信任欢喜的 CA 证书包的文件位置。
当 tcpTransport.url
前缀为 "http://" 时必须不设置,或者设置为空。
如果 tcpTransport.url
前缀为 "https://" 并且此字段未设置,则默认使用系统的信任根。
clientKey
string
clientKey
是与 konnectivity 服务器进行 mtls 握手时使用的客户端秘钥文件位置。
如果 `tcp.url` 前缀为 http://
,必须不指定或者为空;
如果 `tcp.url` 前缀为 https://
,必须设置。
clientCert
string
clientCert
是与 konnectivity 服务器进行 mtls 握手时使用的客户端证书文件位置。
如果 `tcp.url` 前缀为 http://
,必须不指定或者为空;
如果 `tcp.url` 前缀为 https://
,必须设置。
Transport
出现在:
Transport 定义联系 konnectivity 服务器时要使用的传输层配置。
字段 描述
tcp
TCPTransport
tcp
包含通过 TCP 与 konnectivity 服务器通信时使用的 TCP 配置。
目前使用 TCP 传输时不支持 GRPC 的 proxyProtocol
。
tcp
和 uds
二者至少设置一个。
uds
UDSTransport
uds
包含通过 UDS 与 konnectivity 服务器通信时使用的 UDS 配置。
tcp
和 uds
二者至少设置一个。
UDSTransport
出现在:
UDSTransport 设置通过 UDS 连接 konnectivity 服务器时需要的信息。
字段 描述
udsName
[必需]
string
udsName
是与 konnectivity 服务器连接时使用的 UNIX 域套接字名称。
字段取值不要求包含 unix://
前缀。
(例如:/etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket
)
12.6 - kube-proxy 配置 (v1alpha1)
资源类型
KubeProxyConfiguration
KubeProxyConfiguration 包含用来配置 Kubernetes 代理服务器的所有配置信息。
字段 描述
apiVersion
stringkubeproxy.config.k8s.io/v1alpha1
kind
stringKubeProxyConfiguration
featureGates
[必需]
map[string]bool
featureGates 是一个功能特性名称到布尔值的映射表,用来启用或者禁用测试性质的功能特性。
bindAddress
[必需]
string
bindAddress 是代理服务器提供服务时所用 IP 地址(设置为 0.0.0.0
时意味着在所有网络接口上提供服务)。
healthzBindAddress
[必需]
string
healthzBindAddress 是健康状态检查服务器提供服务时所使用的的 IP 地址和端口,
默认设置为 '0.0.0.0:10256'。
metricsBindAddress
[必需]
string
metricsBindAddress 是度量值服务器提供服务时所使用的的 IP 地址和端口,
默认设置为 '127.0.0.1:10249'(设置为 0.0.0.0 意味着在所有接口上提供服务)。
bindAddressHardFail
[必需]
bool
bindAddressHardFail 设置为 true 时,kube-proxy 将无法绑定到某端口这类问题视为致命错误并直接退出。
enableProfiling
[必需]
bool
enableProfiling 通过 '/debug/pprof' 处理程序在 Web 界面上启用性能分析。
性能分析处理程序将由度量值服务器执行。
clusterCIDR
[必需]
string
clusterCIDR 是集群中 Pods 所使用的 CIDR 范围。这一地址范围用于对来自集群外的请求
流量进行桥接。如果未设置,则 kube-proxy 不会对非集群内部的流量做桥接。
hostnameOverride
[必需]
string
hostnameOverride 非空时,所给的字符串(而不是实际的主机名)将被用作 kube-proxy 的标识。
clientConnection
[必需]
ClientConnectionConfiguration
clientConnection 给出代理服务器与 API 服务器通信时要使用的 kubeconfig 文件和客户端链接设置。
iptables
[必需]
KubeProxyIPTablesConfiguration
iptables 字段包含与 iptables 相关的配置选项。
ipvs
[必需]
KubeProxyIPVSConfiguration
ipvs 中包含与 ipvs 相关的配置选项。
oomScoreAdj
[必需]
int32
oomScoreAdj 是为 kube-proxy 进程所设置的 oom-score-adj 值。
此设置值必须介于 [-1000, 1000] 范围内。
mode
[必需]
ProxyMode
mode 用来设置将使用的代理模式。
portRange
[必需]
string
portRange 是主机端口的范围,形式为 ‘beginPort-endPort’(包含边界),
用来设置代理服务所使用的端口。如果未指定(即‘0-0’),则代理服务会随机选择端口号。
udpIdleTimeout
[必需]
meta/v1.Duration
udpIdleTimeout 用来设置 UDP 链接保持活跃的时长(例如,'250ms'、'2s')。
此值必须大于 0。此字段仅适用于 mode 值为 'userspace' 的场合。
conntrack
[必需]
KubeProxyConntrackConfiguration
conntrack 包含与 conntrack 相关的配置选项。
configSyncPeriod
[必需]
meta/v1.Duration
configSyncPeriod 是从 API 服务器刷新配置的频率。此值必须大于 0。
nodePortAddresses
[必需]
[]string
nodePortAddresses 是 kube-proxy 进程的 --nodeport-addresses
命令行参数设置。
此值必须是合法的 IP 段。所给的 IP 段会作为参数来选择 NodePort 类型服务所使用的接口。
如果有人希望将本地主机(Localhost)上的服务暴露给本地访问,同时暴露在某些其他网络接口上
以实现某种目标,可以使用 IP 段的列表。
如果此值被设置为 "127.0.0.0/8",则 kube-proxy 将仅为 NodePort 服务选择本地回路(loopback)接口。
如果此值被设置为非零的 IP 段,则 kube-proxy 会对 IP 作过滤,仅使用适用于当前节点的 IP 地址。
空的字符串列表意味着选择所有网络接口。
winkernel
[必需]
KubeProxyWinkernelConfiguration
winkernel 包含与 winkernel 相关的配置选项。
showHiddenMetricsForVersion
[必需]
string
showHiddenMetricsForVersion 给出的是一个 Kubernetes 版本号字符串,用来设置你希望
显示隐藏度量值的版本。
detectLocalMode
[必需]
LocalMode
detectLocalMode 用来确定检测本地流量的方式,默认为 LocalModeClusterCIDR。
KubeProxyConntrackConfiguration
出现在:
KubeProxyConntrackConfiguration 包含为 Kubernetes 代理服务器提供的 conntrack 设置。
字段 描述
maxPerCore
[必需]
int32
maxPerCore 是每个 CPU 核所跟踪的 NAT 链接个数上限
(0 意味着保留当前上限限制并忽略 min 字段设置值)。
min
[必需]
int32
min 给出要分配的链接跟踪记录个数下限。
设置此值时会忽略 maxPerCore 的值(将 maxPerCore 设置为 0 时不会调整上限值)。
tcpEstablishedTimeout
[必需]
meta/v1.Duration
tcpEstablishedTimeout 给出空闲 TCP 连接的保留时间(例如,'2s')。
此值必须大于 0。
tcpCloseWaitTimeout
[必需]
meta/v1.Duration
tcpCloseWaitTimeout 用来设置空闲的、处于 CLOSE_WAIT 状态的 conntrack 条目
保留在 conntrack 表中的时间长度(例如,'60s')。
此设置值必须大于 0。
KubeProxyIPTablesConfiguration
出现在:
KubeProxyIPTablesConfiguration 包含用于 Kubernetes 代理服务器的、与 iptables 相关的配置细节。
字段 描述
masqueradeBit
[必需]
int32
masqueradeBit 是 iptables fwmark 空间中的具体一位,用来在纯 iptables 代理模式下
设置 SNAT。此值必须介于 [0, 31](含边界值)。
masqueradeAll
[必需]
bool
masqueradeAll 用来通知 kube-proxy 在使用纯 iptables 代理模式时对所有流量执行
SNAT 操作。
syncPeriod
[必需]
meta/v1.Duration
syncPeriod 给出 iptables 规则的刷新周期(例如,'5s'、'1m'、'2h22m')。
此值必须大于 0。
minSyncPeriod
[必需]
meta/v1.Duration
minSyncPeriod 给出 iptables 规则被刷新的最小周期(例如,'5s'、'1m'、'2h22m')。
KubeProxyIPVSConfiguration
出现在:
KubeProxyIPVSConfiguration 包含用于 Kubernetes 代理服务器的、与 ipvs 相关的配置细节。
字段 描述
syncPeriod
[必需]
meta/v1.Duration
syncPeriod 给出 ipvs 规则的刷新周期(例如,'5s'、'1m'、'2h22m')。
此值必须大于 0。
minSyncPeriod
[必需]
meta/v1.Duration
minSyncPeriod 给出 ipvs 规则被刷新的最小周期(例如,'5s'、'1m'、'2h22m')。
scheduler
[必需]
string
IPVS 调度器。
excludeCIDRs
[必需]
[]string
excludeCIDRs 取值为一个 CIDR 列表,ipvs 代理程序在清理 IPVS 服务时不应触碰这些 IP 地址。
strictARP
[必需]
bool
strictARP 用来配置 arp_ignore 和 arp_announce,以避免(错误地)响应来自 kube-ipvs0 接口的
ARP 查询请求。
tcpTimeout
[必需]
meta/v1.Duration
tcpTimeout 是用于设置空闲 IPVS TCP 会话的超时值。
默认值为 0,意味着使用系统上当前的超时值设置。
tcpFinTimeout
[必需]
meta/v1.Duration
tcpFinTimeout 用来设置 IPVS TCP 会话在收到 FIN 之后的超时值。
默认值为 0,意味着使用系统上当前的超时值设置。
udpTimeout
[必需]
meta/v1.Duration
udpTimeout 用来设置 IPVS UDP 包的超时值。
默认值为 0,意味着使用系统上当前的超时值设置。
KubeProxyWinkernelConfiguration
出现在:
KubeProxyWinkernelConfiguration 包含 Kubernetes 代理服务器的 Windows/HNS 设置。
字段 描述
networkName
[必需]
string
networkName 是 kube-proxy 用来创建端点和策略的网络名称。
sourceVip
[必需]
string
sourceVip 是执行负载均衡时进行 NAT 转换所使用的源端 VIP 端点 IP 地址。
enableDSR
[必需]
bool
enableDSR 通知 kube-proxy 是否使用 DSR 来创建 HNS 策略。
LocalMode
(string
类型的别名)
出现在:
LocalMode 代表的是对节点上本地流量进行检测的模式。
ProxyMode
(string
类型的别名)
出现在:
ProxyMode 表示的是 Kubernetes 代理服务器所使用的模式。
目前 Linux 平台上有三种可用的代理模式:'userspace'(相对较老,即将被淘汰)、
'iptables'(相对较新,速度较快)、'ipvs'(最新,在性能和可扩缩性上表现好)。
在 Windows 平台上有两种可用的代理模式:'userspace'(相对较老,但稳定)和
'kernelspace'(相对较新,速度更快)。
在 Linux 平台上,如果代理的 mode 为空,则使用可用的最佳代理(目前是 iptables,
将来可能会发生变化)。如果选择的是 iptables 代理(无论原因如何),但系统的内核
或者 iptables 的版本不够高,kube-proxy 也会回退为 userspace 代理服务器所使用的模式。
当代理的 mode 设置为 'ipvs' 时会启用 IPVS 模式,对应的回退路径是先尝试 iptables,
最后回退到 userspace。
在 Windows 平台上,如果代理 mode 为空,则使用可用的最佳代理(目前是 userspace,
不过将来可能会发生变化)。如果所选择的是 winkernel 代理(无论原因如何),
但 Windows 内核不支持此代理模式,则 kube-proxy 会回退到 userspace 代理。
ClientConnectionConfiguration
出现在:
ClientConnectionConfiguration 包含构造客户端所需要的细节信息。
字段 描述
kubeconfig
[必需]
string
kubeconfig 是指向一个 KubeConfig 文件的路径。
acceptContentTypes
[必需]
string
acceptContentTypes 定义客户端在连接到服务器时所发送的 Accept 头部字段。
此设置值会覆盖默认配置 'application/json'。
此字段会控制某特定客户端与指定服务器的所有链接。
contentType
[必需]
string
contentType 是从此客户端向服务器发送数据时使用的内容类型(Content Type)。
qps
[必需]
float32
qps 控制此连接上每秒钟可以发送的查询请求个数。
burst
[必需]
int32
允许客户端超出其速率限制时可以临时累积的额外查询个数。
FormatOptions 包含不同日志记录格式的配置选项。
字段 描述
json
[必需]
JSONOptions
[实验特性] json 字段包含 “JSON” 日志格式的配置选项。
JSONOptions
出现在:
JSONOptions 包含“json”日志格式的配置选项。
VModuleConfiguration
([]k8s.io/component-base/config/v1alpha1.VModuleItem
的别名)
VModuleConfiguration 是一组文件名或文件名模式,及其对应的日志详尽程度阈值配置。
12.7 - kube-scheduler 配置 (v1beta2)
资源类型
DefaultPreemptionArgs
DefaultPreemptionArgs 包含用来配置 DefaultPreemption 插件的参数。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta2
kind
stringDefaultPreemptionArgs
minCandidateNodesPercentage
[必需]
int32
此字段为试运行抢占时 shortlist 中候选节点数的下限,数值为节点数的百分比。
字段值必须介于 [0, 100] 之间。未指定时默认值为整个集群规模的 10%。
minCandidateNodesAbsolute
[必需]
int32
此字段设置 shortlist 中候选节点的绝对下限。用于试运行抢占而列举的
候选节点个数近似于通过下面的公式计算的:
候选节点数 = max(节点数 * minCandidateNodesPercentage, minCandidateNodesAbsolute)
之所以说是“近似于”是因为存在一些类似于 PDB 违例这种因素,会影响到进入 shortlist
中候选节点的个数。取值至少为 0 节点。若未设置默认为 100 节点。
InterPodAffinityArgs
InterPodAffinityArgs 包含用来配置 InterPodAffinity 插件的参数。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta2
kind
stringInterPodAffinityArgs
hardPodAffinityWeight
[必需]
int32
此字段是一个计分权重值。针对新增的 Pod,要对现存的、带有与新 Pod 匹配的
硬性亲和性设置的 Pod 计算亲和性得分。
KubeSchedulerConfiguration
KubeSchedulerConfiguration 用来配置调度器。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta2
kind
stringKubeSchedulerConfiguration
parallelism
[必需]
int32
此字段设置为调度 Pod 而执行算法时的并发度。此值必须大于 0。
默认值为 16。
leaderElection
[必需]
LeaderElectionConfiguration
此字段用来定义领导者选举客户端的配置。
clientConnection
[必需]
ClientConnectionConfiguration
此字段为与 API 服务器通信时使用的代理服务器设置 kubeconfig 文件和客户端
连接配置。
healthzBindAddress
[必需]
string
healthzBindAddress
是健康检查服务器提供服务所用的 IP 地址和端口。
注意:healthzBindAddress
和 metricsBindAddress
这两个字段都已被弃用。
只可以设置空地址或者端口 0。其他设置值都无法通过合法性检查。
metricsBindAddress
[必需]
string
metricsBindAddress
是度量值服务器提供服务所用的 IP 地址和端口。
DebuggingConfiguration
[必需]
DebuggingConfiguration
(DebuggingConfiguration
的成员被内嵌到此类型中)
此字段设置与调试相关功能特性的配置。
percentageOfNodesToScore
[必需]
int32
此字段为所有节点的百分比,一旦调度器找到所设置比例的、能够运行 Pod 的节点,
则停止在集群中继续寻找更合适的节点。这一配置有助于提高调度器的性能。调度器
总会尝试寻找至少 "minFeasibleNodesToFind" 个可行节点,无论此字段的取值如何。
例如:当集群规模为 500 个节点,而此字段的取值为 30,则调度器在找到 150 个合适
的节点后会停止继续寻找合适的节点。当此值为 0 时,调度器会使用默认节点数百分比(基于集群规模
确定的值,在 5% 到 50% 之间)来执行打分操作。
podInitialBackoffSeconds
[必需]
int64
此字段设置不可调度 Pod 的初始回退秒数。如果设置了此字段,其取值必须大于零。
若此值为 null,则使用默认值(1s)。
podMaxBackoffSeconds
[必需]
int64
此字段设置不可调度的 Pod 的最大回退秒数。如果设置了此字段,则其值必须大于
podInitialBackoffSeconds 字段值。如果此值设置为 null,则使用默认值(10s)。
profiles
[必需]
[]KubeSchedulerProfile
此字段为 kube-scheduler 所支持的方案(profiles)。Pod 可以通过设置其对应
的调度器名称来选择使用特定的方案。未指定调度器名称的 Pod 会使用
“default-scheduler”方案来调度,如果存在的话。
extenders
[必需]
[]Extender
此字段为调度器扩展模块(Extender)的列表,每个元素包含如何与某扩展模块
通信的配置信息。所有调度器模仿会共享此扩展模块列表。
NodeAffinityArgs
NodeAffinityArgs 中包含配置 NodeAffinity 插件的参数。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta2
kind
stringNodeAffinityArgs
addedAffinity
core/v1.NodeAffinity
addedAffinity
会作为附加的亲和性属性添加到所有 Pod 的
规约中指定的 NodeAffinity 中。换言之,节点需要同时满足 addedAffinity
和 .spec.nodeAffinity。默认情况下,addedAffinity 为空(与所有节点匹配)。
使用了 addedAffinity 时,某些带有已经能够与某特定节点匹配的亲和性需求
的 Pod (例如 DaemonSet Pod)可能会继续呈现不可调度状态。
NodeResourcesBalancedAllocationArgs
NodeResourcesBalancedAllocationArgs 包含用来配置 NodeResourcesBalancedAllocation 插件的参数。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta2
kind
stringNodeResourcesBalancedAllocationArgs
resources
[必需]
[]ResourceSpec
要管理的资源;如果未设置,则默认值为 "cpu" 和 "memory"。
NodeResourcesFitArgs
NodeResourcesFitArgs 包含用来配置 NodeResourcesFit 插件的参数。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta2
kind
stringNodeResourcesFitArgs
ignoredResources
[必需]
[]string
此字段为 NodeResources 匹配过滤器要忽略的资源列表。此列表不影响节点打分。
ignoredResourceGroups
[必需]
[]string
此字段定义 NodeResources 匹配过滤器要忽略的资源组列表。
例如,如果配置值为 ["example.com"],则以 "example.com" 开头的资源名(如
"example.com/aaa" 和 "example.com/bbb")都会被忽略。
资源组名称中不可以包含 '/'。此设置不影响节点的打分。
scoringStrategy
[必需]
ScoringStrategy
此字段用来选择节点资源打分策略。默认的策略为 LeastAllocated,且 "cpu" 和
"memory" 的权重相同。
PodTopologySpreadArgs
PodTopologySpreadArgs 包含用来配置 PodTopologySpread 插件的参数。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta2
kind
stringPodTopologySpreadArgs
defaultConstraints
[]core/v1.TopologySpreadConstraint
此字段针对未定义 .spec.topologySpreadConstraints
的 Pod,
为其提供拓扑分布约束。.defaultConstraints[∗].labelSelectors
必须为空,因为这一信息要从 Pod 所属的 Service、ReplicationController、
ReplicaSet 或 StatefulSet 来推导。
此字段不为空时,.defaultingType
必须为 "List"。
defaultingType
PodTopologySpreadConstraintsDefaulting
defaultingType
决定如何推导 .defaultConstraints
。
可选值为 "System" 或 "List"。
"System":使用 Kubernetes 定义的约束,将 Pod 分布到不同节点和可用区;
"List":使用 .defaultConstraints
中定义的约束。
当特性门控 DefaultPodTopologySpread 被禁用时,默认值为 "list";反之,默认值为 "System"。
VolumeBindingArgs
VolumeBindingArgs 包含用来配置 VolumeBinding 插件的参数。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta2
kind
stringVolumeBindingArgs
bindTimeoutSeconds
[必需]
int64
此字段设置卷绑定操作的超时秒数。字段值必须是非负数。
取值为 0 意味着不等待。如果此值为 null,则使用默认值(600)。
shape
[]UtilizationShapePoint
shape
用来设置打分函数曲线所使用的计分点,这些计分点
用来基于静态制备的 PV 卷的利用率为节点打分。
卷的利用率是计算得来的,将 Pod 所请求的总的存储空间大小除以每个节点
上可用的总的卷容量。每个计分点包含利用率(范围从 0 到 100)和其对应
的得分(范围从 0 到 10)。你可以通过为不同的使用率值设置不同的得分来
反转优先级:
默认的曲线计分点为:
利用率为 0 时得分为 0;
利用率为 100 时得分为 10。
所有计分点必须按利用率值的升序来排序。
Extender
出现在:
Extender 包含与扩展模块(Extender)通信所用的参数。
如果未指定 verb 或者 verb 为空,则假定对应的扩展模块选择不提供该扩展功能。
字段 描述
urlPrefix
[必需]
string
用来访问扩展模块的 URL 前缀。
filterVerb
[必需]
string
filter 调用所使用的动词,如果不支持过滤操作则为空。
此动词会在向扩展模块发送 filter 调用时追加到 urlPrefix 后面。
preemptVerb
[必需]
string
preempt 调用所使用的动词,如果不支持抢占操作则为空。
此动词会在向扩展模块发送 preempt 调用时追加到 urlPrefix 后面。
prioritizeVerb
[必需]
string
prioritize 调用所使用的动词,如果不支持 prioritize 操作则为空。
此动词会在向扩展模块发送 prioritize 调用时追加到 urlPrefix 后面。
weight
[必需]
int64
针对 prioritize 调用所生成的节点分数要使用的数值系数。
weight 值必须是正整数。
bindVerb
[必需]
string
bind 调用所使用的动词,如果不支持 bind 操作则为空。
此动词会在向扩展模块发送 bind 调用时追加到 urlPrefix 后面。
如果扩展模块实现了此方法,扩展模块要负责将 Pod 绑定到 API 服务器。
只有一个扩展模块可以实现此函数。
enableHTTPS
[必需]
bool
此字段设置是否需要使用 HTTPS 来与扩展模块通信。
tlsConfig
[必需]
ExtenderTLSConfig
此字段设置传输层安全性(TLS)配置。
httpTimeout
[必需]
meta/v1.Duration
此字段给出扩展模块功能调用的超时值。filter 操作超时会导致 Pod 无法被调度。
prioritize 操作超时会被忽略,Kubernetes 或者其他扩展模块所给出的优先级值
会被用来选择节点。
nodeCacheCapable
[必需]
bool
此字段指示扩展模块可以缓存节点信息,从而调度器应该发送关于可选节点的最少信息,
假定扩展模块已经缓存了集群中所有节点的全部详细信息。
managedResources
[]ExtenderManagedResource
managedResources
是一个由此扩展模块所管理的扩展资源的列表。
如果某 Pod 请求了此列表中的至少一个扩展资源,则 Pod 会在 filter、
prioritize 和 bind (如果扩展模块可以执行绑定操作)阶段被发送到该扩展模块。
若此字段为空或未设置,则所有 Pod 都会发送到此扩展模块。
如果某资源上设置了 ignoredByScheduler
为 true,则 kube-scheduler
会在断言阶段略过对该资源的检查。
ignorable
[必需]
bool
此字段用来设置扩展模块是否是可忽略的。换言之,当扩展模块返回错误或者
完全不可达时,调度操作不应失败。
ExtenderManagedResource
出现在:
ExtenderManagedResource 描述某扩展模块所管理的扩展资源的参数。
字段 描述
name
[必需]
string
扩展资源的名称。
ignoredByScheduler
[必需]
bool
此字段标明 kube-scheduler 是否应在应用断言时忽略此资源。
ExtenderTLSConfig
出现在:
ExtenderTLSConfig 包含启用与扩展模块间 TLS 传输所需的配置参数。
字段 描述
insecure
[必需]
bool
访问服务器时不需要检查 TLS 证书。此配置仅针对测试用途。
serverName
[必需]
string
serverName
会被发送到服务器端,作为 SNI 标志;客户端会使用
此设置来检查服务器证书。如果 serverName
为空,则会使用联系
服务器时所用的主机名。
certFile
[必需]
string
服务器端所要求的 TLS 客户端证书认证。
keyFile
[必需]
string
服务器端所要求的 TLS 客户端秘钥认证。
caFile
[必需]
string
服务器端可信任的根证书。
certData
[必需]
[]byte
certData
包含 PEM 编码的字节流(通常从某客户端证书文件读入)。
此字段优先级高于 certFile 字段。
keyData
[必需]
[]byte
keyData
包含 PEM 编码的字节流(通常从某客户端证书秘钥文件读入)。
此字段优先级高于 keyFile 字段。
caData
[必需]
[]byte
caData
包含 PEM 编码的字节流(通常从某根证书包文件读入)。
此字段优先级高于 caFile 字段。
KubeSchedulerProfile
出现在:
KubeSchedulerProfile 是一个调度方案。
字段 描述
schedulerName
[必需]
string
schedulerName
是与此调度方案相关联的调度器的名称。
如果 schedulerName
与 Pod 的 spec.schedulerName
匹配,则该 Pod 会使用此方案来调度。
plugins
[必需]
Plugins
plugins
设置一组应该被启用或禁止的插件。
被启用的插件是指除了默认插件之外需要被启用的插件。被禁止的插件
是指需要被禁用的默认插件。
如果针对某个扩展点没有设置被启用或被禁止的插件,则使用该扩展点
的默认插件(如果有的话)。如果设置了 QueueSort 插件,则同一个 QueueSort
插件和 pluginConfig
要被设置到所有调度方案之上。
pluginConfig
[必需]
[]PluginConfig
pluginConfig
是为每个插件提供的一组可选的定制插件参数。
如果忽略了插件的配置参数,则意味着使用该插件的默认配置。
Plugin
出现在:
Plugin 指定插件的名称及其权重(如果适用的话)。权重仅用于评分(Score)插件。
字段 描述
name
[必需]
string
插件的名称。
weight
[必需]
int32
插件的权重;仅适用于评分(Score)插件。
PluginConfig
出现在:
PluginConfig 给出初始化阶段要传递给插件的参数。
在多个扩展点被调用的插件仅会被初始化一次。
参数可以是任意结构。插件负责处理这里所传的参数。
PluginSet
出现在:
PluginSet 为某扩展点设置要启用或禁用的插件。
如果数组为空,或者取值为 null,则使用该扩展点的默认插件集合。
字段 描述
enabled
[必需]
[]Plugin
enabled
设置在默认插件之外要启用的插件。如果在调度器的配置
文件中也配置了默认插件,则对应插件的权重会被覆盖。
此处所设置的插件会在默认插件之后被调用,调用顺序与数组中元素顺序相同。
disabled
[必需]
[]Plugin
disabled
设置要被禁用的默认插件。
如果需要禁用所有的默认插件,应该提供仅包含一个元素 "∗" 的数组。
Plugins
出现在:
Plugins 结构中包含多个扩展点。当此结构被设置时,针对特定扩展点所启用
的所有插件都在这一列表中。
如果配置中不包含某个扩展点,则使用该扩展点的默认插件集合。
被启用的插件的调用顺序与这里指定的顺序相同,都在默认插件之后调用。
如果它们需要在默认插件之前调用,则需要先行禁止默认插件,之后在这里
按期望的顺序重新启用。
字段 描述
queueSort
[必需]
PluginSet
queueSort
是一个在对调度队列中 Pod 排序时要调用的插件列表。
preFilter
[必需]
PluginSet
preFilter
是一个在调度框架中“PreFilter(预过滤)”扩展点上要
调用的插件列表。
filter
[必需]
PluginSet
filter
是一个在需要过滤掉无法运行 Pod 的节点时被调用的插件列表。
postFilter
[必需]
PluginSet
postFilter
是一个在过滤阶段结束后会被调用的插件列表;
这里的插件只有在找不到合适的节点来运行 Pod 时才会被调用。
preScore
[必需]
PluginSet
preScore
是一个在打分之前要调用的插件列表。
score
[必需]
PluginSet
score
是一个在对已经通过过滤阶段的节点进行排序时调用的插件的列表。
reserve
[必需]
PluginSet
reserve
是一组在运行 Pod 的节点已被选定后,需要预留或者释放资源时调用的插件的列表。
permit
[必需]
PluginSet
permit
是一个用来控制 Pod 绑定关系的插件列表。这些插件可以
禁止或者延迟 Pod 的绑定。
preBind
[必需]
PluginSet
preBind
是一个在 Pod 被绑定到某节点之前要被调用的插件的列表。
bind
[必需]
PluginSet
bind
是一个在调度框架中“Bind(绑定)”扩展点上要调用的
插件的列表。调度器按顺序调用这些插件。只要其中某个插件返回成功,则调度器
就略过余下的插件。
postBind
[必需]
PluginSet
postBind
是一个在 Pod 已经被成功绑定之后要调用的插件的列表。
multiPoint
[必需]
PluginSet
multiPoint
是一个简化的配置段落,用来为所有合法的扩展点启用插件。
PodTopologySpreadConstraintsDefaulting
(string
类型的别名)
出现在:
PodTopologySpreadConstraintsDefaulting 定义如何为 PodTopologySpread 插件
设置默认的约束。
RequestedToCapacityRatioParam
出现在:
RequestedToCapacityRatioParam 结构定义 RequestedToCapacityRatio 的参数。
ResourceSpec
出现在:
ResourceSpec 用来代表某个资源。
字段 描述
name
[必需]
string
资源名称。
weight
[必需]
int64
资源权重。
ScoringStrategy
出现在:
ScoringStrategy 为节点资源插件定义 ScoringStrategyType。
ScoringStrategyType
(string
数据类型的别名)
出现在:
ScoringStrategyType 是 NodeResourcesFit 插件所使用的的评分策略类型。
UtilizationShapePoint
出现在:
UtilizationShapePoint 代表的是优先级函数曲线中的一个评分点。
字段 描述
utilization
[必需]
int32
利用率(x 轴)。合法值为 0 到 100。完全被利用的节点映射到 100。
score
[必需]
int32
分配给指定利用率的分值(y 轴)。合法值为 0 到 10。
ClientConnectionConfiguration
出现在:
ClientConnectionConfiguration 中包含用来构造一个客户端所需的细节。
字段 描述
kubeconfig
[必需]
string
此字段为指向某 KubeConfig 文件的路径。
acceptContentTypes
[必需]
string
acceptContentTypes
定义的是客户端与服务器建立连接时要发送的
Accept 头部;这里的设置值会覆盖默认值 "application/json"。
此字段会影响某特定客户端与服务器的所有连接。
contentType
[必需]
string
contentType
包含的是此客户端向服务器发送数据时使用的
内容类型(Content Type)。
qps
[必需]
float32
qps
控制的是此连接上每秒可以发送的查询个数。
burst
[必需]
int32
burst
允许在客户端超出其速率限制时可以累积的额外查询个数。
DebuggingConfiguration
出现在:
DebuggingConfiguration 保存与调试功能相关的配置。
字段 描述
enableProfiling
[必需]
bool
此字段允许通过 Web 接口 host:port/debug/pprof/ 执行性能分析。
enableContentionProfiling
[必需]
bool
此字段在 enableProfiling
为 true 时允许执行锁竞争分析。
FormatOptions 中包含不同日志格式的配置选项。
字段 描述
json
[必需]
JSONOptions
[实验特性] json
字段包含为 "json" 日志格式提供的配置选项。
JSONOptions
出现在:
JSONOptions 包含为 "json" 日志格式所设置的配置选项。
字段 描述
splitStream
[必需]
bool
[实验特性] 此字段将错误信息重定向到标准错误输出(stderr),将提示消息
重定向到标准输出(stdout),并且支持缓存。默认配置为将二者都输出到
标准输出(stdout),且不提供缓存。
infoBufferSize
[必需]
k8s.io/apimachinery/pkg/api/resource.QuantityValue
[实验特性] infoBufferSize
用来在分离数据流场景是设置提示
信息数据流的大小。默认值为 0,意味着禁止缓存。
LeaderElectionConfiguration
出现在:
LeaderElectionConfiguration 为能够支持领导者选举的组件定义其领导者选举
客户端的配置。
字段 描述
leaderElect
[必需]
bool
leaderElect
启用领导者选举客户端,从而在进入主循环执行之前
先要获得领导者角色。当运行多副本组件时启用此功能有助于提高可用性。
leaseDuration
[必需]
meta/v1.Duration
leaseDuration
是非领导角色候选者在观察到需要领导席位更新时
要等待的时间;只有经过所设置时长才可以尝试去获得一个仍处于领导状态但需要
被刷新的席位。这里的设置值本质上意味着某个领导者在被另一个候选者替换掉
之前可以停止运行的最长时长。只有当启用了领导者选举时此字段有意义。
renewDeadline
[必需]
meta/v1.Duration
renewDeadline
设置的是当前领导者在停止扮演领导角色之前
需要刷新领导状态的时间间隔。此值必须小于或等于租约期限的长度。
只有到启用了领导者选举时此字段才有意义。
retryPeriod
[必需]
meta/v1.Duration
retryPeriod
是客户端在连续两次尝试获得或者刷新领导状态
之间需要等待的时长。只有当启用了领导者选举时此字段才有意义。
resourceLock
[必需]
string
此字段给出在领导者选举期间要作为锁来使用的资源对象类型。
resourceName
[必需]
string
此字段给出在领导者选举期间要作为锁来使用的资源对象名称。
resourceNamespace
[必需]
string
此字段给出在领导者选举期间要作为锁来使用的资源对象所在名字空间。
VModuleConfiguration
([]k8s.io/component-base/config/v1alpha1.VModuleItem
的别名)
VModuleConfiguration 是一组文件名(通配符)及其对应的日志详尽程度阈值。
12.8 - kube-scheduler 配置 (v1beta3)
资源类型
DefaultPreemptionArgs
DefaultPreemptionArgs 包含用来配置 DefaultPreemption 插件的参数。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta3
kind
stringDefaultPreemptionArgs
minCandidateNodesPercentage
[必需]
int32
此字段为试运行抢占时 shortlist 中候选节点数的下限,数值为节点数的百分比。
字段值必须介于 [0, 100] 之间。未指定时默认值为整个集群规模的 10%。
minCandidateNodesAbsolute
[必需]
int32
此字段设置 shortlist 中候选节点的绝对下限。用于试运行抢占而列举的
候选节点个数近似于通过下面的公式计算的:
候选节点数 = max(节点数 * minCandidateNodesPercentage, minCandidateNodesAbsolute)
之所以说是“近似于”是因为存在一些类似于 PDB 违例这种因素,会影响到进入 shortlist
中候选节点的个数。取值至少为 0 节点。若未设置默认为 100 节点。
InterPodAffinityArgs
InterPodAffinityArgs 包含用来配置 InterPodAffinity 插件的参数。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta3
kind
stringInterPodAffinityArgs
hardPodAffinityWeight
[必需]
int32
此字段是一个计分权重值。针对新增的 Pod,要对现存的、带有与新 Pod 匹配的
硬性亲和性设置的 Pods 计算亲和性得分。
KubeSchedulerConfiguration
KubeSchedulerConfiguration 用来配置调度器。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta3
kind
stringKubeSchedulerConfiguration
parallelism
[必需]
int32
此字段设置为调度 Pod 而执行算法时的并发度。此值必须大于 0。
默认值为 16。
leaderElection
[必需]
LeaderElectionConfiguration
此字段用来定义领导者选举客户端的配置。
clientConnection
[必需]
ClientConnectionConfiguration
此字段为与 API 服务器通信时使用的代理服务器设置 kubeconfig 文件和客户端
连接配置。
DebuggingConfiguration
[必需]
DebuggingConfiguration
(DebuggingConfiguration
的成员被内嵌到此类型中)
此字段设置与调试相关功能特性的配置。
percentageOfNodesToScore
[必需]
int32
此字段为所有节点的百分比,一旦调度器找到所设置比例的、能够运行 Pod 的节点,
则停止在集群中继续寻找更合适的节点。这一配置有助于提高调度器的性能。调度器
总会尝试寻找至少 "minFeasibleNodesToFind" 个可行节点,无论此字段的取值如何。
例如:当集群规模为 500 个节点,而此字段的取值为 30,则调度器在找到 150 个合适
的节点后会停止继续寻找合适的节点。当此值为 0 时,调度器会使用默认节点数百分比(基于集群规模
确定的值,在 5% 到 50% 之间)来执行打分操作。
podInitialBackoffSeconds
[必需]
int64
此字段设置不可调度 Pod 的初始回退秒数。如果设置了此字段,其取值必须大于零。
若此值为 null,则使用默认值(1s)。
podMaxBackoffSeconds
[必需]
int64
此字段设置不可调度的 Pod 的最大回退秒数。如果设置了此字段,则其值必须大于
podInitialBackoffSeconds 字段值。如果此值设置为 null,则使用默认值(10s)。
profiles
[必需]
[]KubeSchedulerProfile
此字段为 kube-scheduler 所支持的方案(profiles)。Pod 可以通过设置其对应
的调度器名称来选择使用特定的方案。未指定调度器名称的 Pod 会使用
“default-scheduler”方案来调度,如果存在的话。
extenders
[必需]
[]Extender
此字段为调度器扩展模块(Extender)的列表,每个元素包含如何与某扩展模块
通信的配置信息。所有调度器模仿会共享此扩展模块列表。
NodeAffinityArgs
NodeAffinityArgs 中包含配置 NodeAffinity 插件的参数。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta3
kind
stringNodeAffinityArgs
addedAffinity
core/v1.NodeAffinity
addedAffinity
会作为附加的亲和性属性添加到所有 Pod 的
规约中指定的 NodeAffinity 中。换言之,节点需要同时满足 addedAffinity
和 .spec.nodeAffinity。默认情况下,addedAffinity 为空(与所有节点匹配)。
使用了 addedAffinity 时,某些带有已经能够与某特定节点匹配的亲和性需求
的 Pod (例如 DaemonSet Pod)可能会继续呈现不可调度状态。
NodeResourcesBalancedAllocationArgs
NodeResourcesBalancedAllocationArgs 包含用来配置 NodeResourcesBalancedAllocation 插件的参数。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta3
kind
stringNodeResourcesBalancedAllocationArgs
resources
[必需]
[]ResourceSpec
要管理的资源;如果未设置,则默认值为 "cpu" 和 "memory"。
NodeResourcesFitArgs
NodeResourcesFitArgs 包含用来配置 NodeResourcesFit 插件的参数。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta3
kind
stringNodeResourcesFitArgs
ignoredResources
[必需]
[]string
此字段为 NodeResources 匹配过滤器要忽略的资源列表。此列表不影响节点打分。
ignoredResourceGroups
[必需]
[]string
此字段定义 NodeResources 匹配过滤器要忽略的资源组列表。
例如,如果配置值为 ["example.com"],则以 "example.com" 开头的资源名(如
"example.com/aaa" 和 "example.com/bbb")都会被忽略。
资源组名称中不可以包含 '/'。此设置不影响节点的打分。
scoringStrategy
[必需]
ScoringStrategy
此字段用来选择节点资源打分策略。默认的策略为 LeastAllocated,且 "cpu" 和
"memory" 的权重相同。
PodTopologySpreadArgs
PodTopologySpreadArgs 包含用来配置 PodTopologySpread 插件的参数。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta3
kind
stringPodTopologySpreadArgs
defaultConstraints
[]core/v1.TopologySpreadConstraint
此字段针对未定义 .spec.topologySpreadConstraints
的 Pod,
为其提供拓扑分布约束。.defaultConstraints[∗].labelSelectors
必须为空,因为这一信息要从 Pod 所属的 Service、ReplicationController、
ReplicaSet 或 StatefulSet 来推导。
此字段不为空时,.defaultingType
必须为 "List"。
defaultingType
PodTopologySpreadConstraintsDefaulting
defaultingType
决定如何推导 .defaultConstraints
。
可选值为 "System" 或 "List"。
"System":使用 Kubernetes 定义的约束,将 Pod 分布到不同节点和可用区;
"List":使用 .defaultConstraints
中定义的约束。
当特性门控 DefaultPodTopologySpread 被禁用时,默认值为 "list";反之,默认值为 "System"。
VolumeBindingArgs
VolumeBindingArgs 包含用来配置 VolumeBinding 插件的参数。
字段 描述
apiVersion
stringkubescheduler.config.k8s.io/v1beta3
kind
stringVolumeBindingArgs
bindTimeoutSeconds
[必需]
int64
此字段设置卷绑定操作的超时秒数。字段值必须是非负数。
取值为 0 意味着不等待。如果此值为 null,则使用默认值(600)。
shape
[]UtilizationShapePoint
shape
用来设置打分函数曲线所使用的计分点,这些计分点
用来基于静态制备的 PV 卷的利用率为节点打分。
卷的利用率是计算得来的,将 Pod 所请求的总的存储空间大小除以每个节点
上可用的总的卷容量。每个计分点包含利用率(范围从 0 到 100)和其对应
的得分(范围从 0 到 10)。你可以通过为不同的使用率值设置不同的得分来
反转优先级:
默认的曲线计分点为:
利用率为 0 时得分为 0;
利用率为 100 时得分为 10。
所有计分点必须按利用率值的升序来排序。
Extender
出现在:
Extender 包含与扩展模块(Extender)通信所用的参数。
如果未指定 verb 或者 verb 为空,则假定对应的扩展模块选择不提供该扩展功能。
字段 描述
urlPrefix
[必需]
string
用来访问扩展模块的 URL 前缀。
filterVerb
[必需]
string
filter 调用所使用的动词,如果不支持过滤操作则为空。
此动词会在向扩展模块发送 filter 调用时追加到 urlPrefix 后面。
preemptVerb
[必需]
string
preempt 调用所使用的动词,如果不支持过滤操作则为空。
此动词会在向扩展模块发送 preempt 调用时追加到 urlPrefix 后面。
prioritizeVerb
[必需]
string
prioritize 调用所使用的动词,如果不支持过滤操作则为空。
此动词会在向扩展模块发送 prioritize 调用时追加到 urlPrefix 后面。
weight
[必需]
int64
针对 prioritize 调用所生成的节点分数要使用的数值系数。
weight 值必须是正整数。
bindVerb
[必需]
string
bind 调用所使用的动词,如果不支持过滤操作则为空。
此动词会在向扩展模块发送 bind 调用时追加到 urlPrefix 后面。
如果扩展模块实现了此方法,扩展模块要负责将 Pod 绑定到 API 服务器。
只有一个扩展模块可以实现此函数。
enableHTTPS
[必需]
bool
此字段设置是否需要使用 HTTPS 来与扩展模块通信。
tlsConfig
[必需]
ExtenderTLSConfig
此字段设置传输层安全性(TLS)配置。
httpTimeout
[必需]
meta/v1.Duration
此字段给出扩展模块功能调用的超时值。filter 操作超时会导致 Pod 无法被调度。
prioritize 操作超时会被忽略,Kubernetes 或者其他扩展模块所给出的优先级值
会被用来选择节点。
nodeCacheCapable
[必需]
bool
此字段指示扩展模块可以缓存节点信息,从而调度器应该发送关于可选节点的最少信息,
假定扩展模块已经缓存了集群中所有节点的全部详细信息。
managedResources
[]ExtenderManagedResource
managedResources
是一个由此扩展模块所管理的扩展资源的列表。
如果某 Pod 请求了此列表中的至少一个扩展资源,则 Pod 会在 filter、
prioritize 和 bind (如果扩展模块可以执行绑定操作)阶段被发送到该扩展模块。
如果某资源上设置了 ignoredByScheduler
为 true,则 kube-scheduler
会在断言阶段略过对该资源的检查。
ignorable
[必需]
bool
此字段用来设置扩展模块是否是可忽略的。换言之,当扩展模块返回错误或者
完全不可达时,调度操作不应失败。
ExtenderManagedResource
出现在:
ExtenderManagedResource 描述某扩展模块所管理的扩展资源的参数。
字段 描述
name
[必需]
string
扩展资源的名称。
ignoredByScheduler
[必需]
bool
此字段标明 kube-scheduler 是否应在应用断言时忽略此资源。
ExtenderTLSConfig
出现在:
ExtenderTLSConfig 包含启用与扩展模块间 TLS 传输所需的配置参数。
字段 描述
insecure
[必需]
bool
访问服务器时不需要检查 TLS 证书。此配置仅针对测试用途。
serverName
[必需]
string
serverName
会被发送到服务器端,作为 SNI 标志;客户端会使用
此设置来检查服务器证书。如果 serverName
为空,则会使用联系
服务器时所用的主机名。
certFile
[必需]
string
服务器端所要求的 TLS 客户端证书认证。
keyFile
[必需]
string
服务器端所要求的 TLS 客户端秘钥认证。
caFile
[必需]
string
服务器端被信任的根证书。
certData
[必需]
[]byte
certData
包含 PEM 编码的字节流(通常从某客户端证书文件读入)。
此字段优先级高于 certFile 字段。
keyData
[必需]
[]byte
keyData
包含 PEM 编码的字节流(通常从某客户端证书秘钥文件读入)。
此字段优先级高于 keyFile 字段。
caData
[必需]
[]byte
caData
包含 PEM 编码的字节流(通常从某根证书包文件读入)。
此字段优先级高于 caFile 字段。
KubeSchedulerProfile
出现在:
KubeSchedulerProfile 是一个调度方案。
字段 描述
schedulerName
[必需]
string
schedulerName
是与此调度方案相关联的调度器的名称。
如果 schedulerName
与 Pod 的 spec.schedulerName
匹配,则该 Pod 会使用此方案来调度。
plugins
[必需]
Plugins
plugins
设置一组应该被启用或禁止的插件。
被启用的插件是指除了默认插件之外需要被启用的插件。被禁止的插件
是指需要被禁用的默认插件。
如果针对某个扩展点没有设置被启用或被禁止的插件,则使用该扩展点
的默认插件(如果有的话)。如果设置了 QueueSort 插件,则同一个 QueueSort
插件和 pluginConfig
要被设置到所有调度方案之上。
pluginConfig
[必需]
[]PluginConfig
pluginConfig
是为每个插件提供的一组可选的定制插件参数。
如果忽略了插件的配置参数,则意味着使用该插件的默认配置。
Plugin
出现在:
Plugin 指定插件的名称及其权重(如果适用的话)。权重仅用于评分(Score)插件。
字段 描述
name
[必需]
string
插件的名称。
weight
[必需]
int32
插件的权重;仅适用于评分(Score)插件。
PluginConfig
出现在:
PluginConfig 给出初始化阶段要传递给插件的参数。
在多个扩展点被调用的插件仅会被初始化一次。
参数可以是任意结构。插件负责处理这里所传的参数。
PluginSet
出现在:
PluginSet 为某扩展点设置要启用或禁用的插件。
如果数组为空,或者取值为 null,则使用该扩展点的默认插件集合。
字段 描述
enabled
[必需]
[]Plugin
enabled
设置在默认插件之外要启用的插件。如果在调度器的配置
文件中也配置了默认插件,则对应插件的权重会被覆盖。
此处所设置的插件会在默认插件之后被调用,调用顺序与数组中元素顺序相同。
disabled
[必需]
[]Plugin
disabled
设置要被禁用的默认插件。
如果需要禁用所有的默认插件,应该提供仅包含一个元素 "∗" 的数组。
Plugins
出现在:
Plugins 结构中包含多个扩展点。当此结构被设置时,针对特定扩展点所启用
的所有插件都在这一列表中。
如果配置中不包含某个扩展点,则使用该扩展点的默认插件集合。
被启用的插件的调用顺序与这里指定的顺序相同,都在默认插件之后调用。
如果它们需要在默认插件之前调用,则需要先行禁止默认插件,之后在这里
按期望的顺序重新启用。
字段 描述
queueSort
[必需]
PluginSet
queueSort
是一个在对调度队列中 Pod 排序时要调用的插件列表。
preFilter
[必需]
PluginSet
preFilter
是一个在调度框架中“PreFilter(预过滤)”扩展点上要
调用的插件列表。
filter
[必需]
PluginSet
filter
是一个在需要过滤掉无法运行 Pod 的节点时被调用的插件列表。
postFilter
[必需]
PluginSet
postFilter
是一个在过滤阶段结束后会被调用的插件列表;
这里的插件只有在找不到合适的节点来运行 Pod 时才会被调用。
preScore
[必需]
PluginSet
preScore
是一个在打分之前要调用的插件列表。
score
[必需]
PluginSet
score
是一个在对已经通过过滤阶段的节点进行排序时调用的插件的列表。
reserve
[必需]
PluginSet
reserve
是一组在运行 Pod 的节点已被选定后,需要预留或者释放资源时调用的插件的列表。
permit
[必需]
PluginSet
permit
是一个用来控制 Pod 绑定关系的插件列表。这些插件可以
禁止或者延迟 Pod 的绑定。
preBind
[必需]
PluginSet
preBind
是一个在 Pod 被绑定到某节点之前要被调用的插件的列表。
bind
[必需]
PluginSet
bind
是一个在调度框架中“Bind(绑定)”扩展点上要调用的
插件的列表。调度器按顺序调用这些插件。只要其中某个插件返回成功,则调度器
就略过余下的插件。
postBind
[必需]
PluginSet
postBind
是一个在 Pod 已经被成功绑定之后要调用的插件的列表。
multiPoint
[必需]
PluginSet
multiPoint
是一个简化的配置段落,用来为所有合法的扩展点启用插件。
通过 multiPoint
启用的插件会自动注册到插件所实现的每个独立的扩展点上。
通过 multiPoint
禁用的插件会禁用对应的操作行为。
通过 multiPoint
所禁止的 "∗" 也是如此,意味着所有默认
插件都不会被自动注册。
插件也可以通过各个独立的扩展点来禁用。
就优先序而言,插件配置遵从以下基本层次:
特定的扩展点;
显式配置的 multiPoint
插件;
默认插件的集合,以及 multiPoint
插件。
这意味着优先序较高的插件会先被运行,并且覆盖 multiPoint
中的任何配置。
用户显式配置的插件也会比默认插件优先序高。
在这样的层次结构设计之下,enabled
的优先序高于 disabled
。
例如,某插件同时出现在 multiPoint.enabled
和 multiPoint.disalbed
时,
该插件会被启用。类似的,同时设置 multiPoint.disabled = '∗'
和 multiPoint.enabled = pluginA
时,插件 pluginA 仍然会被注册。
这一设计与所有其他扩展点的配置行为是相符的。
PodTopologySpreadConstraintsDefaulting
(string
类型的别名)
出现在:
PodTopologySpreadConstraintsDefaulting 定义如何为 PodTopologySpread 插件
设置默认的约束。
RequestedToCapacityRatioParam
出现在:
RequestedToCapacityRatioParam 结构定义 RequestedToCapacityRatio 的参数。
ResourceSpec
出现在:
ResourceSpec 用来代表某个资源。
字段 描述
name
[必需]
string
资源名称。
weight
[必需]
int64
资源权重。
ScoringStrategy
出现在:
ScoringStrategy 为节点资源插件定义 ScoringStrategyType。
ScoringStrategyType
(string
数据类型的别名)
出现在:
ScoringStrategyType 是 NodeResourcesFit 插件所使用的的评分策略类型。
UtilizationShapePoint
出现在:
UtilizationShapePoint 代表的是优先级函数曲线中的一个评分点。
字段 描述
utilization
[必需]
int32
利用率(x 轴)。合法值为 0 到 100。完全被利用的节点映射到 100。
score
[必需]
int32
分配给指定利用率的分值(y 轴)。合法值为 0 到 10。
ClientConnectionConfiguration
出现在:
ClientConnectionConfiguration 中包含用来构造一个客户端所需的细节。
字段 描述
kubeconfig
[必需]
string
此字段为指向某 KubeConfig 文件的路径。
acceptContentTypes
[必需]
string
acceptContentTypes
定义的是客户端与服务器建立连接时要发送的
Accept 头部;这里的设置值会覆盖默认值 "application/json"。
此字段会影响某特定客户端与服务器的所有连接。
contentType
[必需]
string
contentType
包含的是此客户端向服务器发送数据时使用的
内容类型(Content Type)。
qps
[必需]
float32
qps
控制的是此连接上每秒可以发送的查询个数。
burst
[必需]
int32
burst
允许在客户端超出其速率限制时可以累积的额外查询个数。
DebuggingConfiguration
出现在:
DebuggingConfiguration 保存与调试功能相关的配置。
字段 描述
enableProfiling
[必需]
bool
此字段允许通过 Web 接口 host:port/debug/pprof/ 执行性能分析。
enableContentionProfiling
[必需]
bool
此字段在 enableProfiling
为 true 时允许执行锁竞争分析。
FormatOptions 中包含不同日志格式的配置选项。
字段 描述
json
[必需]
JSONOptions
[实验特性] json
字段包含为 "json" 日志格式提供的配置选项。
JSONOptions
出现在:
JSONOptions 包含为 "json" 日志格式所设置的配置选项。
字段 描述
splitStream
[必需]
bool
[实验特性] 此字段将错误信息重定向到标准错误输出(stderr),将提示消息
重定向到标准输出(stdout),并且支持缓存。默认配置为将二者都输出到
标准输出(stdout),且不提供缓存。
infoBufferSize
[必需]
k8s.io/apimachinery/pkg/api/resource.QuantityValue
[实验特性] infoBufferSize
用来在分离数据流场景是设置提示
信息数据流的大小。默认值为 0,意味着禁止缓存。
LeaderElectionConfiguration
出现在:
LeaderElectionConfiguration 为能够支持领导者选举的组件定义其领导者选举
客户端的配置。
字段 描述
leaderElect
[必需]
bool
leaderElect
启用领导者选举客户端,从而在进入主循环执行之前
先要获得领导者角色。当运行多副本组件时启用此功能有助于提高可用性。
leaseDuration
[必需]
meta/v1.Duration
leaseDuration
是非领导角色候选者在观察到需要领导席位更新时
要等待的时间;只有经过所设置时长才可以尝试去获得一个仍处于领导状态但需要
被刷新的席位。这里的设置值本质上意味着某个领导者在被另一个候选者替换掉
之前可以停止运行的最长时长。只有当启用了领导者选举时此字段有意义。
renewDeadline
[必需]
meta/v1.Duration
renewDeadline
设置的是当前领导者在停止扮演领导角色之前
需要刷新领导状态的时间间隔。此值必须小于或等于租约期限的长度。
只有到启用了领导者选举时此字段才有意义。
retryPeriod
[必需]
meta/v1.Duration
retryPeriod
是客户端在连续两次尝试获得或者刷新领导状态
之间需要等待的时长。只有当启用了领导者选举时此字段才有意义。
resourceLock
[必需]
string
此字段给出在领导者选举期间要作为锁来使用的资源对象类型。
resourceName
[必需]
string
此字段给出在领导者选举期间要作为锁来使用的资源对象名称。
resourceNamespace
[必需]
string
此字段给出在领导者选举期间要作为锁来使用的资源对象所在名字空间。
VModuleConfiguration
([]k8s.io/component-base/config/v1alpha1.VModuleItem
的别名)
VModuleConfiguration 是一组文件名(通配符)及其对应的日志详尽程度阈值。
12.9 - kubeadm 配置 (v1beta2)
概述
包 v1beta2 定义 kubeadm 配置文件格式的 v1beta2 版本。
此版本改进了 v1beta1 的格式,修复了一些小问题并添加了一些新的字段。
从 v1beta1 版本以来的变更列表:
"certificateKey" 字段被添加到 InitConfiguration 和 JoinConfiguration 中。
"ignorePreflightErrors" 字段被添加到 NodeRegistrationOptions 中。
JSON 标签 "omitempty" 在合适的情况下被用到更多的位置。
"taints" 字段(在 NodeRegistrationOptions)的 JSON 标签 "omitempty" 被去除。
参阅 Kubernetes 1.15 的变更记录以了解详细信息。
从老的 kubeadm 配置版本迁移:
请使用 kubeadm v1.15.x 的 "kubeadm config migrate" 命令将 v1beta1
版本的配置文件转换为 v1beta2。
(从更老版本的 kubeadm 配置文件迁移需要使用更老版本的 kubeadm。例如:
kubeadm v1.11 版本可以用来从 v1alpha1 迁移到 v1alpha2 版本;kubeadm v1.12
可用来将 v1alpha2 翻译为 v1alpha3。
kubeadm v1.13 或 v1.14 可以用来将 v1alpha3 迁移到 v1beta1。
)
尽管如此,kubeadm v1.15.x 会支持读取 v1beta1 版本的 kubeadm 配置文件格式。
基础知识
配置 kubeadm 的推荐方式是使用 --config
选项向其传递一个 YAML 配置文件。
kubeadm 配置文件中定义的某些配置选项也可以作为命令行标志来使用,
不过这种方法所支持的都是一些最常见的、最简单的使用场景。
一个 kubeadm 配置文件中可以包含多个配置类型,使用三根横线(---
)作为分隔符。
kubeadm 支持以下配置类型:
apiVersion : kubeadm.k8s.io/v1beta2
kind : InitConfiguration
apiVersion : kubeadm.k8s.io/v1beta2
kind : ClusterConfiguration
apiVersion : kubelet.config.k8s.io/v1beta1
kind : KubeletConfiguration
apiVersion : kubeproxy.config.k8s.io/v1alpha1
kind : KubeProxyConfiguration
apiVersion : kubeadm.k8s.io/v1beta2
kind : JoinConfiguration
要输出 "init" 和 "join" 动作的默认值,可以使用下面的命令:
kubeadm config print init-defaults
kubeadm config print join-defaults
配置文件中必须包含的配置类型列表取决于你在执行的动作(init
或 join
),
也取决于你要使用的配置选项(默认值或者高级定制)。
如果某些配置类型没有提供,或者仅部分提供,kubeadm 将使用默认值;
kubeadm 所提供的默认值在必要时也会保证其在多个组件之间是一致的
(例如控制器管理器上的 --cluster-cidr
参数和 kube-proxy 上的
clusterCIDR
)。
用户总是可以重载默认配置值,唯一的例外是一小部分与安全性相关联的配置
(例如在 API 服务器上强制实施 Node 和 RBAC 鉴权模式)。
如果用户所提供的配置类型并非你所执行的操作需要的,
kubeadm 会忽略这些配置类型并打印警告信息。
kubeadm init 配置类型
当带有 --config
选项来执行 kubeadm init 命令时,可以使用下面的配置类型:
InitConfiguration
、ClusterConfiguration
、KubeProxyConfiguration
、
KubeletConfiguration
,但 InitConfiguration
和 ClusterConfiguration
之间只有一个是必须提供的。
apiVersion : kubeadm.k8s.io/v1beta2
kind : InitConfiguration
bootstrapTokens :
...
nodeRegistration :
...
类型 InitConfiguration 用来配置运行时设置,就 kubeadm init 命令而言,
包括启动引导令牌以及所有与 kubeadm 所在节点相关的设置,包括:
nodeRegistration
:其中包含与向集群注册新节点相关的字段;
使用这个类型来定制节点名称、要使用的 CRI 套接字或者其他仅对当前节点起作用的设置
(例如节点 IP 地址)。
apiServer
:代表的是要部署到此节点上的 API 服务器示例的端点;
使用这个类型可以完成定制 API 服务器公告地址这类操作。
apiVersion : kubeadm.k8s.io/v1beta2
kind : ClusterConfiguration
networking :
...
etcd :
...
apiServer :
extraArgs :
...
extraVolumes :
...
...
类型 ClusterConfiguration
用来定制集群范围的设置,具体包括以下设置:
networking
:其中包含集群的网络拓扑配置。使用这一部分可以定制 Pod
的子网或者 Service 的子网。
etcd
:etcd 数据库的配置。例如使用这个部分可以定制本地 etcd 或者配置
API 服务器使用一个外部的 etcd 集群。
kube-apiserver
、kube-scheduler
、kube-controller-manager
配置:这些部分可以通过添加定制的设置或者重载 kubeadm 的默认设置来定制控制面组件。
apiVersion : kubeproxy.config.k8s.io/v1alpha1
kind : KubeProxyConfiguration
...
KubeProxyConfiguration 类型用来更改传递给在集群中部署的 kube-proxy 实例的配置。
如果此对象没有提供,或者仅部分提供,kubeadm 使用默认值。
关于 kube-proxy 的官方文档,可参阅
https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-proxy/
或者 https://godoc.org/k8s.io/kube-proxy/config/v1alpha1#KubeProxyConfiguration。
apiVersion : kubelet.config.k8s.io/v1beta1
kind : KubeletConfiguration
...
KubeletConfiguration 类型用来更改传递给在集群中部署的 kubelet 实例的配置。
如果此对象没有提供,或者仅部分提供,kubeadm 使用默认值。
关于 kubelet 的官方文档,可参阅
https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kubelet/
或者
https://godoc.org/k8s.io/kubelet/config/v1beta1#KubeletConfiguration。
下面是一个为执行 kubeadm init
而提供的、包含多个配置类型的单一 YAML 文件,
其中填充了很多部分。
apiVersion : kubeadm.k8s.io/v1beta2
kind : InitConfiguration
bootstrapTokens :
- token : "9a08jv.c0izixklcxtmnze7"
description : "kubeadm bootstrap token"
ttl : "24h"
- token : "783bde.3f89s0fje9f38fhf"
description : "another bootstrap token"
usages :
- authentication
- signing
groups :
- system:bootstrappers:kubeadm:default-node-token
nodeRegistration :
name : "ec2-10-100-0-1"
criSocket : "/var/run/dockershim.sock"
taints :
- key : "kubeadmNode"
value : "master"
effect : "NoSchedule"
kubeletExtraArgs :
v : 4
ignorePreflightErrors :
- IsPrivilegedUser
localAPIEndpoint :
advertiseAddress : "10.100.0.1"
bindPort : 6443
certificateKey : "e6a2eb8581237ab72a4f494f30285ec12a9694d750b9785706a83bfcbbbd2204"
---
apiVersion : kubeadm.k8s.io/v1beta2
kind : ClusterConfiguration
etcd :
# one of local or external
local :
imageRepository : "k8s.gcr.io"
imageTag : "3.2.24"
dataDir : "/var/lib/etcd"
extraArgs :
listen-client-urls : "http://10.100.0.1:2379"
serverCertSANs :
- "ec2-10-100-0-1.compute-1.amazonaws.com"
peerCertSANs :
- "10.100.0.1"
# external:
# endpoints:
# - "10.100.0.1:2379"
# - "10.100.0.2:2379"
# caFile: "/etcd/kubernetes/pki/etcd/etcd-ca.crt"
# certFile: "/etcd/kubernetes/pki/etcd/etcd.crt"
# keyFile: "/etcd/kubernetes/pki/etcd/etcd.key"
networking :
serviceSubnet : "10.96.0.0/16"
podSubnet : "10.244.0.0/24"
dnsDomain : "cluster.local"
kubernetesVersion : "v1.12.0"
controlPlaneEndpoint : "10.100.0.1:6443"
apiServer :
extraArgs :
authorization-mode : "Node,RBAC"
extraVolumes :
- name : "some-volume"
hostPath : "/etc/some-path"
mountPath : "/etc/some-pod-path"
readOnly : false
pathType : File
certSANs :
- "10.100.1.1"
- "ec2-10-100-0-1.compute-1.amazonaws.com"
timeoutForControlPlane : 4m0s
controllerManager :
extraArgs :
"node-cidr-mask-size": "20"
extraVolumes :
- name : "some-volume"
hostPath : "/etc/some-path"
mountPath : "/etc/some-pod-path"
readOnly : false
pathType : File
scheduler :
extraArgs :
address : "10.100.0.1"
extraVolumes :
- name : "some-volume"
hostPath : "/etc/some-path"
mountPath : "/etc/some-pod-path"
readOnly : false
pathType : File
certificatesDir : "/etc/kubernetes/pki"
imageRepository : "k8s.gcr.io"
useHyperKubeImage : false
clusterName : "example-cluster"
---
apiVersion : kubelet.config.k8s.io/v1beta1
kind : KubeletConfiguration
# kubelet specific options here
---
apiVersion : kubeproxy.config.k8s.io/v1alpha1
kind : KubeProxyConfiguration
# kube-proxy specific options here
kubeadm join 配置类型
当带有 --config
选项来执行 kubeadm join
操作时,
需要提供 JoinConfiguration 类型。
apiVersion : kubeadm.k8s.io/v1beta2
kind : JoinConfiguration
...
JoinConfiguration 类型用来配置运行时设置,就 kubeadm join
而言包括用来访问集群信息的发现方法,以及所有特定于 kubeadm 执行所在节点的设置,
包括:
nodeRegistration
:其中包含向集群注册新节点相关的配置字段;
使用这个类型可以定制节点名称、用使用的 CRI 套接字和所有其他仅适用于当前节点的设置
(例如节点 IP 地址)。
apiEndpoint
:用来代表最终要部署到此节点上的 API
服务器实例的端点。
资源类型
ClusterConfiguration
ClusterConfiguration 包含一个 kubadm 集群的集群范围配置信息。
字段 描述
apiVersion
stringkubeadm.k8s.io/v1beta2
kind
stringClusterConfiguration
etcd
[必需]
Etcd
etcd
中包含 etcd 服务的配置。
networking
[必需]
Networking
networking
字段包含集群的网络拓扑配置。
kubernetesVersion
[必需]
string
kubernetesVersion
设置控制面的目标版本。
controlPlaneEndpoint
[必需]
string
controlPlaneEndpoint
为控制面设置一个稳定的 IP 地址或 DNS 名称。
取值可以是一个合法的 IP 地址或者 RFC-1123 形式的 DNS 子域名,二者均可以带一个可选的
TCP 端口号。
如果 controlPlaneEndpoint
未设置,则使用 advertiseAddress
+ bindPort
。
如果设置了 controlPlaneEndpoint
,但未指定 TCP 端口号,则使用
bindPort
。
可能的用法有:
在一个包含不止一个控制面实例的集群中,
该字段应该设置为放置在控制面实例之前的外部负载均衡器的地址。
在带有强制性节点回收的环境中,controlPlaneEndpoint
可以用来为控制面设置一个稳定的 DNS。
apiServer
[必需]
APIServer
apiServer
包含 API 服务器的一些额外配置。
controllerManager
[必需]
ControlPlaneComponent
controllerManager
中包含控制器管理器的额外配置。
scheduler
[必需]
ControlPlaneComponent
scheduler
包含调度器的额外配置。
dns
[必需]
DNS
dns
定义在集群中安装的 DNS 插件的选项。
certificatesDir
[必需]
string
certificatesDir
设置在何处存放或者查找所需证书。
imageRepository
[必需]
string
imageRepository
设置用来拉取镜像的容器仓库。
如果此字段为空,默认使用 k8s.gcr.io
;
当 Kubernetes 用来执行 CI 构造时(Kubernetes 版本以 ci/
开头),
将默认使用 gcr.io/k8s-staging-ci-images
来拉取控制面组件镜像,
而使用 k8s.gcr.io
来拉取所有其他镜像。
useHyperKubeImage
[必需]
bool
useHyperKubeImage
控制是否使用 hyperkube 来作为Kubernetes
组件,而不是一个个独立的镜像。
已启用:由于 hyperkube
自身已被弃用,此字段也被启用。
将被从将来的 kubeadm 配置版本中移除,kubeadm 在此字段设置为 true
时会打印多个警告信息,并且在一些其他位置忽略此字段设置。
featureGates
[必需]
map[string]bool
featureGates
包含用户所启用的特性门控。
clusterName
[必需]
string
集群名称。
ClusterStatus
ClusterStatus 包含集群信息。ClusterStatus 会被保存在集群中 kubeadm-config
ConfigMap 中,之后在新的控制面实例添加到集群或者现有控制面实例离开集群时被更新。
字段 描述
apiVersion
stringkubeadm.k8s.io/v1beta2
kind
stringClusterStatus
apiEndpoints
[必需]
map[string]APIEndpoint
apiEndpoints
为当前集群中可用的 API 端点,每个控制面实例
(API 服务器)对应一个表项。
映射的键名为主机默认接口的 IP 地址。
InitConfiguration
InitConfiguration 包含一组特定于 "kubeadm init" 的运行时元素。
字段 描述
apiVersion
stringkubeadm.k8s.io/v1beta2
kind
stringInitConfiguration
bootstrapTokens
[必需]
[]BootstrapToken
bootstrapTokens
在 kubeadm init
执行时会被用到,
其中描述了一组要创建的启动引导令牌(Bootstrap Tokens)。
这里的信息不会被上传到 kubeadm 在集群中保存的 ConfigMap 中,部分原因是由于信息本身比较敏感。
nodeRegistration
[必需]
NodeRegistrationOptions
nodeRegistration
中包含与向集群中注册新的控制面节点相关的字段。
localAPIEndpoint
[必需]
APIEndpoint
localAPIEndpoint
所代表的的是在此控制面节点上要部署的 API 服务器的端点。
在高可用(HA)配置中,此字段与 ClusterConfiguration.controlPlaneEndpoint
的取值不同:后者代表的是整个集群的全局端点,该端点上的请求会被负载均衡到每个 API 服务器。
此配置对象允许你定制本地 API 服务器所公布的、可访问的 IP/DNS 名称和端口。
默认情况下,kubeadm 会尝试自动检测默认接口上的 IP 并使用该地址。
不过,如果这种检测失败,你可以在此字段中直接设置所期望的值。
certificateKey
[必需]
string
certificateKey
用来设置一个秘钥,该秘钥将对 uploadcerts init
阶段上传到集群中某 Secret 内的秘钥和证书加密。
JoinConfiguration
JoinConfiguration 包含描述特定节点的元素。
字段 描述
apiVersion
stringkubeadm.k8s.io/v1beta2
kind
stringJoinConfiguration
nodeRegistration
[必需]
NodeRegistrationOptions
nodeRegistration
包含与向集群注册控制面节点相关的字段。
caCertPath
[必需]
string
caCertPath
是指向 SSL 证书机构的路径,
该证书包用来加密节点与控制面之间的通信。默认值为
"/etc/kubernetes/pki/ca.crt"。
discovery
[必需]
Discovery
discovery
设置 TLS 引导过程中 kubelet 要使用的选项。
controlPlane
[必需]
JoinControlPlane
controlPlane
定义要在正被加入到集群中的节点上部署的额外控制面实例。
此字段为 null 时,不会再上面部署额外的控制面实例。
APIEndpoint
出现在:
APIEndpoint 结构包含某节点上部署的 API 服务器的配置元素。
字段 描述
advertiseAddress
[必需]
string
advertiseAddress
设置 API 服务器要公布的 IP 地址。
bindPort
[必需]
int32
bindPort
设置 API 服务器要绑定到的安全端口。默认值为 6443。
APIServer
出现在:
APIServer 包含集群中 API 服务器部署所必需的设置。
字段 描述
ControlPlaneComponent
[必需]
ControlPlaneComponent
(ControlPlaneComponent
结构的字段被嵌入到此类型中)
无描述
certSANs
[必需]
[]string
certSANs
设置 API 服务器签署证书所用的额外主题替代名(Subject Alternative Name,SAN)。
timeoutForControlPlane
[必需]
meta/v1.Duration
timeoutForControlPlane
用来控制我们等待 API 服务器开始运行的超时时间。
BootstrapToken
出现在:
BootstrapToken 描述的是一个启动引导令牌,以 Secret 形式存储在集群中。
字段 描述
token
[必需]
BootstrapTokenString
token
用来在节点与控制面之间建立双向的信任关系。
在向集群中添加节点时使用。
description
[必需]
string
description
设置一个对人友好的消息,
说明为什么此令牌会存在以及其目标用途,这样其他管理员能够知道其目的。
ttl
[必需]
meta/v1.Duration
ttl
定义此令牌的声明周期。默认为 24h
。
expires
和 ttl
是互斥的。
expires
[必需]
meta/v1.Time
expires
设置此令牌过期的时间戳。
默认为在运行时基于ttl
来决定。
expires
和ttl
是互斥的。
usages
[必需]
[]string
usages
描述此令牌的可能使用方式。默认情况下,
令牌可用于建立双向的信任关系;不过这里可以改变默认用途。
groups
[必需]
[]string
groups
设定此令牌被用于身份认证时对应的附加用户组。
BootstrapTokenDiscovery
出现在:
BootstrapTokenDiscovery 用来设置基于引导令牌的服务发现选项。
字段 描述
token
[必需]
string
token
用来验证从控制面获得的集群信息。
apiServerEndpoint
[必需]
string
apiServerEndpoint
为 API 服务器的 IP 地址或者域名,从该端点可以获得集群信息。
caCertHashes
[必需]
[]string
caCertHashes
设置一组在基于令牌来发现服务时要验证的公钥指纹。
发现过程中获得的根 CA 必须与这里的数值之一匹配。
设置为空集合意味着禁用根 CA 指纹,因而可能是不安全的。
每个哈希值的形式为 "<type>:<value>",当前唯一支持的 type 为
"sha256"。
哈希值为主体公钥信息(Subject Public Key Info,SPKI)对象的 SHA-256
哈希值(十六进制编码),形式为 DER 编码的 ASN.1。
例如,这些哈希值可以使用 OpenSSL 来计算。
unsafeSkipCAVerification
[必需]
bool
unsafeSkipCAVerification
允许在使用基于令牌的服务发现时不使用
caCertHashes
来执行 CA 验证。这会弱化 kubeadm 的安全性,
因为其他节点可以伪装成控制面。
BootstrapTokenString
出现在:
BootstrapTokenString 形式为 abcdef.abcdef0123456789
的一个令牌,
用来从加入集群的节点角度验证 API 服务器的身份,或者 "kubeadm join"
在节点启动引导是作为一种身份认证方法。
此令牌的生命期是短暂的,并且应该如此。
字段 描述
id
[必需]
string
无描述
secret
[必需]
string
无描述
ControlPlaneComponent
出现在:
ControlPlaneComponent 中包含对集群中所有控制面组件都适用的设置。
字段 描述
extraArgs
[必需]
map[string]string
extraArgs
是要传递给控制面组件的一组额外的参数标志。
此映射中的每个键对应命令行上使用的标志名称,只是没有其引导连字符。
extraVolumes
[必需]
[]HostPathMount
extraVolumes
是一组额外的主机卷,需要挂载到控制面组件中。
DNS
出现在:
DNS 结构定义要在集群中使用的 DNS 插件。
字段 描述
type
[必需]
DNSAddOnType
type
定义要使用的 DNS 插件类型。
ImageMeta
[必需]
ImageMeta
(ImageMeta
的成员被内嵌到此类型中)。
imageMeta
允许对 DNS 组件所使用的的镜像作定制。
DNSAddOnType
(string
数据类型的别名)
出现在:
DNSAddOnType 定义的是用来辨识 DNS 插件类型的字符串。
Discovery
出现在:
Discovery 设置 TLS 启动引导过程中 kubelet 要使用的配置选项。
字段 描述
bootstrapToken
[必需]
BootstrapTokenDiscovery
bootstrapToken
设置基于启动引导令牌的服务发现选项。
bootstrapToken
与 file
是互斥的。
file
[必需]
FileDiscovery
用来设置一个文件或者 URL 路径,指向一个 kubeconfig 文件;
该配置文件中包含集群信息。
bootstrapToken
与 file
是互斥的。
tlsBootstrapToken
[必需]
string
tlsBootstrapToken
是 TLS 启动引导过程中使用的令牌。
如果设置了 bootstrapToken
,则此字段默认值为 .bootstrapToken.token
,
不过可以被重载。
如果设置了 file
,此字段必须被设置 ,以防 kubeconfig
文件中不包含其他身份认证信息。
timeout
[必需]
meta/v1.Duration
timeout
用来修改发现过程的超时时长。
Etcd
出现在:
Etcd 包含用来描述 etcd 配置的元素。
字段 描述
local
[必需]
LocalEtcd
local
提供配置本地 etcd 实例的选项。local
和
external
是互斥的。
external
[必需]
ExternalEtcd
external
描述如何连接到外部的 etcd 集群。
local
和external
是互斥的。
ExternalEtcd
出现在:
ExternalEtcd 描述外部 etcd 集群。
kubeadm 不清楚证书文件的存放位置,因此必须单独提供证书信息。
字段 描述
endpoints
[必需]
[]string
endpoints
包含一组 etcd 成员的列表。
caFile
[必需]
string
caFile
是一个 SSL 证书机构(CA)文件,用来加密 etcd 通信。
如果使用 TLS 连接,此字段为必需字段。
certFile
[必需]
string
certFile
是一个 SSL 证书文件,用来加密 etcd 通信。
如果使用 TLS 连接,此字段为必需字段。
keyFile
[必需]
string
keyFile
是一个用来加密 etcd 通信的 SSL 秘钥文件。
此字段在使用 TLS 连接时为必填字段。
FileDiscovery
出现在:
FileDiscovery 用来指定一个文件或者 URL 路径,指向一个 kubeconfig 文件;
该配置文件可用来加载集群信息。
字段 描述
kubeConfigPath
[必需]
string
kubeConfigPath
用来指定一个文件或者 URL 路径,指向一个 kubeconfig 文件;
该配置文件可用来加载集群信息。
HostPathMount
出现在:
HostPathMount 包含从宿主节点挂载的卷的信息。
字段 描述
name
[必需]
string
name
为卷在 Pod 模板中的名称。
hostPath
[必需]
string
hostPath
是要在 Pod 中挂载的卷在宿主系统上的路径。
mountPath
[必需]
string
mountPath
是 hostPath
在 Pod 内挂载的路径。
readOnly
[必需]
bool
readOnly
控制卷的读写访问模式。
pathType
[必需]
core/v1.HostPathType
pathType
是 hostPath
的类型。
出现在:
ImageMeta 用来配置来源不是 Kubernetes/kubernetes
发布过程的组件所使用的镜像。
字段 描述
imageRepository
[必需]
string
imageRepository
设置镜像拉取所用的容器仓库。
若未设置,则使用 ClusterConfiguration 中的 imageRepository
。
imageTag
[必需]
string
imageTag
允许用户设置镜像的标签。
如果设置了此字段,则 kubeadm 不再在集群升级时自动更改组件的版本。
JoinControlPlane
出现在:
JoinControlPlane 包含在正在加入集群的节点上要部署的额外的控制面组件的设置。
字段 描述
localAPIEndpoint
[必需]
APIEndpoint
localAPIEndpoint
代表的是将在此节点上部署的 API 服务器实例的端点。
certificateKey
[必需]
string
certificateKey
是在添加新的控制面节点时用来解密所下载的
Secret 中的证书的秘钥。对应的加密秘钥在 InitConfiguration 结构中。
LocalEtcd
出现在:
LocalEtcd 描述的是 kubeadm 要使用的本地 etcd 集群。
字段 描述
ImageMeta
[必需]
ImageMeta
(ImageMeta
结构的字段被嵌入到此类型中。)
ImageMeta 允许用户为 etcd 定制要使用的容器。
dataDir
[必需]
string
dataDir
是 etcd 用来存放数据的目录。
默认值为 "/var/lib/etcd"。
extraArgs
[必需]
map[string]string
extraArgs
是为 etcd 可执行文件提供的额外参数,用于在静态
Pod 中运行 etcd。映射中的每一个键对应命令行上的一个标志参数,只是去掉了前置的连字符。
serverCertSANs
[必需]
[]string
serverCertSANs
为 etcd 服务器的签名证书设置额外的主体替代名
(Subject Alternative Names,SAN)。
peerCertSANs
[必需]
[]string
peerCertSANs
为 etcd 的对等端签名证书设置额外的主体替代名
(Subject Alternative Names,SAN)。
Networking
出现在:
Networking 中包含描述集群网络配置的元素。
字段 描述
serviceSubnet
[必需]
string
serviceSubnet
是 Kubernetes 服务所使用的的子网。
默认值为 "10.96.0.0/12"。
podSubnet
[必需]
string
podSubnet
为 Pod 所使用的子网。
dnsDomain
[必需]
string
dnsDomain
是 Kubernetes 服务所使用的的 DNS 域名。
默认值为 "cluster.local"。
NodeRegistrationOptions
出现在:
NodeRegistrationOptions 包含向集群中注册新的控制面或节点所需要的信息;
节点注册可能通过 "kubeadm init" 或 "kubeadm join" 完成。
字段 描述
name
[必需]
string
name
是 Node API 对象的 .metadata.name
字段值;
该 API 对象会在此 kubeadm init
或 kubeadm join
操作期间创建。
在提交给 API 服务器的 kubelet 客户端证书中,此字段也用作其 CommonName
。
如果未指定则默认为节点的主机名。
criSocket
[必需]
string
criSocket
用来读取容器运行时的信息。
此信息会被以注解的方式添加到 Node API 对象至上,用于后续用途。
taints
[必需]
[]core/v1.Taint
tains
设定 Node API 对象被注册时要附带的污点。
若未设置此字段(即字段值为 null), 在 kubeadm init
期间,节点与控制面之间的通信。
默认值为污点默认设置为 taints: ["node-role.kubernetes.io/master:""]
。
如果你不希望为控制面节点设置污点,可以在 YAML 中将此字段设置为空的列表,即
taints: []
。 此字段仅用在 Node 注册期间。
kubeletExtraArgs
[必需]
map[string]string
kubeletExtraArgs
用来向 kubelet 传递额外参数。
这里的参数会通过 kubeadm 在运行时写入的、由 kubelet 来读取的环境文件来传递给 kubelet 命令行。
这里的设置会覆盖掉 'kubelet-config-1.X' ConfigMap 中包含的一般性的配置。
命令行标志在解析时优先级更高。
这里的设置值仅作用于 kubeadm 运行所在的节点。
映射中的每个键对应命令行中的一个标志参数,只是去掉了前置的连字符。
ignorePreflightErrors
[必需]
[]string
ignorePreflightErrors
提供一组在当前节点被注册时可以忽略掉的预检错误。
12.10 - kubeadm 配置 (v1beta3)
概述
包 v1beta3 定义 kubeadm 配置文件格式的 v1beta3 版本。
此版本改进了 v1beta2 的格式,修复了一些小问题并添加了一些新的字段。
从 v1beta2 版本以来的变更列表:
已弃用的字段 "ClusterConfiguration.useHyperKubeImage" 现在被移除。
kubeadm 不再支持 hyperkube 镜像。
字段 "ClusterConfiguration.dns.type" 已经被移除,因为 CoreDNS 是 kubeadm 所支持
的唯一 DNS 服务器类型。
保存私密信息的字段现在包含了 "datapolicy" 标记(tag)。
这一标记会导致 API 结构通过 klog 打印输出时,会忽略这些字段的值。
添加了 "InitConfiguration.skipPhases", "JoinConfiguration.skipPhases",
以允许在执行 kubeadm init/join 命令时略过某些阶段。
添加了 "InitConfiguration.nodeRegistration.imagePullPolicy" 和
"JoinConfiguration.nodeRegistration.imagePullPolicy"
以允许在 kubeadm init 和 kubeadm join 期间指定镜像拉取策略。
这两个字段的值必须是 "Always"、"Never" 或 "IfNotPresent" 之一。
默认值是 "IfNotPresent",也是添加此字段之前的默认行为。
添加了 "InitConfiguration.patches.directory",
"JoinConfiguration.patches.directory" 以允许用户配置一个目录,
kubeadm 将从该目录中提取组件的补丁包。
BootstrapToken∗ API 和相关的工具被从 "kubeadm" API 组中移出,
放到一个新的 "bootstraptoken" 组中。kubeadm API 版本 v1beta3 不再包含
BootstrapToken∗ 结构。
从老的 kubeadm 配置版本迁移:
kubeadm v1.15.x 及更新的版本可以用来从 v1beta1 迁移到 v1beta2 版本;
kubeadm v1.22.x 及更新的版本不再支持 v1beta1 和更老的 API,但可以用来
从 v1beta2 迁移到 v1beta3。
基础知识
配置 kubeadm 的推荐方式是使用 --config
选项向其传递一个 YAML 配置文件。
kubeadm 配置文件中定义的某些配置选项也可以作为命令行标志来使用,不过这种
方法所支持的都是一些最常见的、最简单的使用场景。
一个 kubeadm 配置文件中可以包含多个配置类型,使用三根横线(---
)作为分隔符。
kubeadm 支持以下配置类型:
apiVersion : kubeadm.k8s.io/v1beta3
kind : InitConfiguration
apiVersion : kubeadm.k8s.io/v1beta3
kind : ClusterConfiguration
apiVersion : kubelet.config.k8s.io/v1beta1
kind : KubeletConfiguration
apiVersion : kubeproxy.config.k8s.io/v1alpha1
kind : KubeProxyConfiguration
apiVersion : kubeadm.k8s.io/v1beta3
kind : JoinConfiguration
要输出 "init" 和 "join" 动作的默认值,可以使用下面的命令:
kubeadm config print init-defaults
kubeadm config print join-defaults
配置文件中必须包含的配置类型列表取决于你在执行的动作(init
或 join
),
也取决于你要使用的配置选项(默认值或者高级定制)。
如果某些配置类型没有提供,或者仅部分提供,kubeadm 将使用默认值;
kubeadm 所提供的默认值在必要时也会保证其在多个组件之间是一致的
(例如控制器管理器上的 --cluster-cidr
参数和 kube-proxy 上的
clusterCIDR
)。
用户总是可以重载默认配置值,唯一的例外是一小部分与安全性相关联的配置
(例如在 API 服务器上强制实施 Node 和 RBAC 鉴权模式)。
如果用户所提供的配置类型并非你所执行的操作需要的,kubeadm 会忽略这些配置类型
并打印警告信息。
kubeadm init 配置类型
当带有 --config
选项来执行 kubeadm init 命令时,可以使用下面的配置类型:
`InitConfiguration`、`ClusterConfiguration`、`KubeProxyConfiguration`、`KubeletConfiguration`,
但 `InitConfiguration` 和 `ClusterConfiguration`
之间只有一个是必须提供的。
apiVersion : kubeadm.k8s.io/v1beta3
kind : InitConfiguration
bootstrapTokens :
...
nodeRegistration :
...
类型 InitConfiguration 用来配置运行时设置,就 kubeadm init 命令而言,包括
启动引导令牌以及所有与 kubeadm 所在节点相关的设置,包括:
nodeRegistration:其中包含与向集群注册新节点相关的字段;使用这个类型来
定制节点名称、要使用的 CRI 套接字或者其他仅对当前节点起作用的设置
(例如节点 IP 地址)。
localAPIEndpoint:代表的是要部署到此节点上的 API 服务器示例的端点;
使用这个类型可以完成定制 API 服务器公告地址这类操作。
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
networking:
...
etcd:
...
apiServer:
extraArgs:
...
extraVolumes:
...
...
类型 `ClusterConfiguration` 用来定制集群范围的设置,具体包括以下设置:
networking
:其中包含集群的网络拓扑配置。使用这一部分可以定制 Pod 的
子网或者 Service 的子网。
etcd
:etcd 数据库的配置。例如使用这个部分可以定制本地 etcd 或者配置 API 服务器
使用一个外部的 etcd 集群。
kube-apiserver
、kube-scheduler
、kube-controller-manager
配置:这些部分可以通过添加定制的设置或者重载 kubeadm 的默认设置来定制控制面组件。
apiVersion : kubeproxy.config.k8s.io/v1alpha1
kind : KubeProxyConfiguration
...
KubeProxyConfiguration 类型用来更改传递给在集群中部署的 kube-proxy 实例
的配置。如果此对象没有提供,或者仅部分提供,kubeadm 使用默认值。
关于 kube-proxy 的官方文档,可参阅
https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-proxy/
或者 https://godoc.org/k8s.io/kube-proxy/config/v1alpha1#KubeProxyConfiguration。
apiVersion : kubelet.config.k8s.io/v1beta1
kind : KubeletConfiguration
...
KubeletConfiguration 类型用来更改传递给在集群中部署的 kubelet 实例的配置。
如果此对象没有提供,或者仅部分提供,kubeadm 使用默认值。
关于 kubelet 的官方文档,可参阅
https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kubelet/
或者
https://godoc.org/k8s.io/kubelet/config/v1beta1#KubeletConfiguration。
下面是一个为执行 kubeadm init
而提供的、包含多个配置类型的单一 YAML 文件,
其中填充了很多部分。
apiVersion : kubeadm.k8s.io/v1beta3
kind : InitConfiguration
bootstrapTokens :
- token : "9a08jv.c0izixklcxtmnze7"
description : "kubeadm bootstrap token"
ttl : "24h"
- token : "783bde.3f89s0fje9f38fhf"
description : "another bootstrap token"
usages :
- authentication
- signing
groups :
- system:bootstrappers:kubeadm:default-node-token
nodeRegistration :
name : "ec2-10-100-0-1"
criSocket : "/var/run/dockershim.sock"
taints :
- key : "kubeadmNode"
value : "master"
effect : "NoSchedule"
kubeletExtraArgs :
v : 4
ignorePreflightErrors :
- IsPrivilegedUser
imagePullPolicy : "IfNotPresent"
localAPIEndpoint :
advertiseAddress : "10.100.0.1"
bindPort : 6443
certificateKey : "e6a2eb8581237ab72a4f494f30285ec12a9694d750b9785706a83bfcbbbd2204"
skipPhases :
- addon/kube-proxy
---
apiVersion : kubeadm.k8s.io/v1beta3
kind : ClusterConfiguration
etcd :
# one of local or external
local :
imageRepository : "k8s.gcr.io"
imageTag : "3.2.24"
dataDir : "/var/lib/etcd"
extraArgs :
listen-client-urls : "http://10.100.0.1:2379"
serverCertSANs :
- "ec2-10-100-0-1.compute-1.amazonaws.com"
peerCertSANs :
- "10.100.0.1"
# external:
# endpoints:
# - "10.100.0.1:2379"
# - "10.100.0.2:2379"
# caFile: "/etcd/kubernetes/pki/etcd/etcd-ca.crt"
# certFile: "/etcd/kubernetes/pki/etcd/etcd.crt"
# keyFile: "/etcd/kubernetes/pki/etcd/etcd.key"
networking :
serviceSubnet : "10.96.0.0/16"
podSubnet : "10.244.0.0/24"
dnsDomain : "cluster.local"
kubernetesVersion : "v1.21.0"
controlPlaneEndpoint : "10.100.0.1:6443"
apiServer :
extraArgs :
authorization-mode : "Node,RBAC"
extraVolumes :
- name : "some-volume"
hostPath : "/etc/some-path"
mountPath : "/etc/some-pod-path"
readOnly : false
pathType : File
certSANs :
- "10.100.1.1"
- "ec2-10-100-0-1.compute-1.amazonaws.com"
timeoutForControlPlane : 4m0s
controllerManager :
extraArgs :
"node-cidr-mask-size": "20"
extraVolumes :
- name : "some-volume"
hostPath : "/etc/some-path"
mountPath : "/etc/some-pod-path"
readOnly : false
pathType : File
scheduler :
extraArgs :
address : "10.100.0.1"
extraVolumes :
- name : "some-volume"
hostPath : "/etc/some-path"
mountPath : "/etc/some-pod-path"
readOnly : false
pathType : File
certificatesDir : "/etc/kubernetes/pki"
imageRepository : "k8s.gcr.io"
clusterName : "example-cluster"
---
apiVersion : kubelet.config.k8s.io/v1beta1
kind : KubeletConfiguration
# kubelet specific options here
---
apiVersion : kubeproxy.config.k8s.io/v1alpha1
kind : KubeProxyConfiguration
# kube-proxy specific options here
kubeadm join 配置类型
当带有 --config
选项来执行 kubeadm join
操作时,
需要提供 JoinConfiguration 类型。
apiVersion : kubeadm.k8s.io/v1beta3
kind : JoinConfiguration
...
JoinConfiguration 类型用来配置运行时设置,就 kubeadm join
而言包括
用来访问集群信息的发现方法,以及所有特定于 kubeadm 执行所在节点的设置,包括:
nodeRegistration
:其中包含向集群注册新节点相关的配置字段;
使用这个类型可以定制节点名称、用使用的 CRI 套接字和所有其他仅适用于当前节点的设置
(例如节点 IP 地址)。
apiEndpoint
:用来代表最终要部署到此节点上的 API
服务器实例的端点。
资源类型
ClusterConfiguration
ClusterConfiguration 包含一个 kubadm 集群的集群范围配置信息。
字段 描述
apiVersion
stringkubeadm.k8s.io/v1beta3
kind
stringClusterConfiguration
etcd
Etcd
etcd
中包含 etcd 服务的配置。
networking
Networking
networking
字段包含集群的网络拓扑配置。
kubernetesVersion
string
kubernetesVersion
设置控制面的目标版本。
controlPlaneEndpoint
string
controlPlaneEndpoint
为控制面设置一个稳定的 IP 地址或 DNS 名称。
取值可以是一个合法的 IP 地址或者 RFC-1123 形式的 DNS 子域名,二者均可以带一个
可选的 TCP 端口号。
如果 controlPlaneEndpoint
未设置,则使用 advertiseAddress
+ bindPort
。
如果设置了 controlPlaneEndpoint
,但未指定 TCP 端口号,则使用
bindPort
。
可能的用法有:
在一个包含不止一个控制面实例的集群中,该字段应该设置为放置在控制面
实例之前的外部负载均衡器的地址。
在带有强制性节点回收的环境中,controlPlaneEndpoint
可以用来
为控制面设置一个稳定的 DNS。
apiServer
APIServer
apiServer
包含 API 服务器的一些额外配置。
controllerManager
ControlPlaneComponent
controllerManager
中包含控制器管理器的额外配置。
scheduler
ControlPlaneComponent
scheduler
包含调度器的额外配置。
dns
DNS
dns
定义在集群中安装的 DNS 插件的选项。
certificatesDir
string
certificatesDir
设置在何处存放或者查找所需证书。
imageRepository
string
imageRepository
设置用来拉取镜像的容器仓库。
如果此字段为空,默认使用 k8s.gcr.io
。
当 Kubernetes 用来执行 CI 构造时(Kubernetes 版本以 ci/
开头),
将默认使用 gcr.io/k8s-staging-ci-images
来拉取控制面组件镜像,
而使用 k8s.gcr.io
来拉取所有其他镜像。
featureGates
map[string]bool
featureGates
包含用户所启用的特性门控。
clusterName
string
集群名称。
InitConfiguration
InitConfiguration 包含一组特定于 "kubeadm init" 的运行时元素。
这里的字段仅用于第一次运行 kubeadm init
命令。
之后,此结构中的字段信息不会再被上传到 kubeadm upgrade
所要使用的
kubeadm-config
ConfigMap 中。
这些字段必须设置 "omitempty"
字段 描述
apiVersion
stringkubeadm.k8s.io/v1beta3
kind
stringInitConfiguration
bootstrapTokens
[]BootstrapToken
bootstrapTokens
在 kubeadm init
执行时会被用到,
其中描述了一组要创建的启动引导令牌(Bootstrap Tokens)。
这里的信息不会被上传到 kubeadm 在集群中保存的 ConfigMap 中,部分原因是由于信息
本身比较敏感。
nodeRegistration
NodeRegistrationOptions
nodeRegistration
中包含与向集群中注册新的控制面节点相关的字段。
localAPIEndpoint
APIEndpoint
localAPIEndpoint
所代表的的是在此控制面节点上要部署的 API 服务器
的端点。在高可用(HA)配置中,此字段与 ClusterConfiguration.controlPlaneEndpoint
的取值不同:后者代表的是整个集群的全局端点,该端点上的请求会被负载均衡到每个
API 服务器。
此配置对象允许你定制本地 API 服务器所公布的、可访问的 IP/DNS 名称和端口。
默认情况下,kubeadm 会尝试自动检测默认接口上的 IP 并使用该地址。
不过,如果这种检测失败,你可以在此字段中直接设置所期望的值。
certificateKey
string
certificateKey
用来设置一个秘钥,该秘钥将对 uploadcerts init
阶段上传到集群中某 Secret 内的秘钥和证书加密。
skipPhases
[]string
skipPhases
是命令执行过程中药略过的阶段(Phases)。
通过执行命令 kubeadm init --help
可以获得阶段的列表。
参数标志 "--skip-phases" 优先于此字段的设置。
patches
Patches
patches
包含与 kubeadm init
阶段 kubeadm 所部署
的组件上要应用的补丁相关的信息。
JoinConfiguration
JoinConfiguration 包含描述特定节点的元素。
字段 描述
apiVersion
stringkubeadm.k8s.io/v1beta3
kind
stringJoinConfiguration
nodeRegistration
NodeRegistrationOptions
nodeRegistration
包含与向集群注册控制面节点相关的字段。
caCertPath
string
caCertPath
是指向 SSL 证书机构的路径,该证书包用来加密
节点与控制面之间的通信。默认值为 "/etc/kubernetes/pki/ca.crt"。
discovery
[必需]-->[必需]
Discovery
discovery
设置 TLS 引导过程中 kubelet 要使用的选项。
controlPlane
JoinControlPlane
controlPlane
定义要在正被加入到集群中的节点上部署的额外
控制面实例。此字段为 null 时,不会再上面部署额外的控制面实例。
skipPhases
[]string
此字段包含在命令执行过程中要略过的阶段。通过 kubeadm join --help
命令可以查看阶段的列表。参数 --skip-phases
优先于此字段。
patches
Patches
此字段包含 kubeadm join
阶段向 kubeadm 所部署的组件打补丁
的选项。
APIEndpoint
出现在:
APIEndpoint 结构包含某节点上部署的 API 服务器的配置元素。
字段 描述
advertiseAddress
string
advertiseAddress
设置 API 服务器要公布的 IP 地址。
bindPort
int32
bindPort
设置 API 服务器要绑定到的安全端口。默认值为 6443。
APIServer
出现在:
APIServer 包含集群中 API 服务器部署所必需的设置。
字段 描述
ControlPlaneComponent
[必需]-->[必需]
ControlPlaneComponent
(ControlPlaneComponent
结构的字段被嵌入到此类型中)
无描述.
certSANs
[]string
certSANs
设置 API 服务器签署证书所用的额外主题替代名(Subject Alternative Name,SAN)。
timeoutForControlPlane
meta/v1.Duration
timeoutForControlPlane
用来控制我们等待 API 服务器开始运行的超时时间。
BootstrapTokenDiscovery
出现在:
BootstrapTokenDiscovery 用来设置基于引导令牌的服务发现选项。
字段 描述
token
[必需]-->[必需]
string
token
用来验证从控制面获得的集群信息。
apiServerEndpoint
string
apiServerEndpoint
为 API 服务器的 IP 地址或者域名,从该端点可以获得集群信息。
caCertHashes
[]string
caCertHashes
设置一组在基于令牌来发现服务时要验证的公钥指纹。
发现过程中获得的根 CA 必须与这里的数值之一匹配。
设置为空集合意味着禁用根 CA 指纹,因而可能是不安全的。
每个哈希值的形式为 "<type>:<value>",当前唯一支持的 type 为
"sha256"。
哈希值为主体公钥信息(Subject Public Key Info,SPKI)对象的 SHA-256
哈希值(十六进制编码),形式为 DER 编码的 ASN.1。
例如,这些哈希值可以使用 OpenSSL 来计算。
unsafeSkipCAVerification
bool
unsafeSkipCAVerification
允许在使用基于令牌的服务发现时
不使用 caCertHashes
来执行 CA 验证。这会弱化 kubeadm 的安全性,
因为其他节点可以伪装成控制面。
ControlPlaneComponent
出现在:
ControlPlaneComponent 中包含对集群中所有控制面组件都适用的设置。
字段 描述
extraArgs
map[string]string
extraArgs
是要传递给控制面组件的一组额外的参数标志。
此映射中的每个键对应命令行上使用的标志名称,只是没有其引导连字符。
extraVolumes
[]HostPathMount
extraVolumes
是一组额外的主机卷,需要挂载到控制面组件中。
DNS
出现在:
DNS 结构定义要在集群中使用的 DNS 插件。
字段 描述
ImageMeta
[必需]-->[必需]
ImageMeta
(ImageMeta
的成员被内嵌到此类型中)。
imageMeta
允许对 DNS 组件所使用的的镜像作定制。
Discovery
出现在:
Discovery 设置 TLS 启动引导过程中 kubelet 要使用的配置选项。
字段 描述
bootstrapToken
BootstrapTokenDiscovery
bootstrapToken
设置基于启动引导令牌的服务发现选项。
bootstrapToken
与 file
是互斥的。
file
FileDiscovery
用来设置一个文件或者 URL 路径,指向一个 kubeconfig 文件;该配置文件
中包含集群信息。
bootstrapToken
与 file
是互斥的。
tlsBootstrapToken
string
tlsBootstrapToken
是 TLS 启动引导过程中使用的令牌。
如果设置了 bootstrapToken
,则此字段默认值为 .bootstrapToken.token
,不过可以被重载。
如果设置了 file
,此字段必须被设置 ,以防 kubeconfig 文件
中不包含其他身份认证信息。
timeout
meta/v1.Duration
timeout
用来修改发现过程的超时时长。
Etcd
出现在:
Etcd 包含用来描述 etcd 配置的元素。
字段 描述
local
LocalEtcd
local
提供配置本地 etcd 实例的选项。local
和
external
是互斥的。
external
ExternalEtcd
external
描述如何连接到外部的 etcd 集群。
external
是互斥的。
ExternalEtcd
出现在:
ExternalEtcd 描述外部 etcd 集群。
kubeadm 不清楚证书文件的存放位置,因此必须单独提供证书信息。
字段 描述
endpoints
[必需]-->[必需]
[]string
endpoints
包含一组 etcd 成员的列表。
caFile
[必需]-->[必需]
string
caFile
是一个 SSL 证书机构(CA)文件,用来加密 etcd 通信。
如果使用 TLS 连接,此字段为必需字段。
certFile
[必需]
string
certFile
是一个 SSL 证书文件,用来加密 etcd 通信。
如果使用 TLS 连接,此字段为必需字段。
keyFile
[必需]
string
keyFile
是一个用来加密 etcd 通信的 SSL 秘钥文件。
此字段在使用 TLS 连接时为必填字段。
FileDiscovery
出现在:
FileDiscovery 用来指定一个文件或者 URL 路径,指向一个 kubeconfig 文件;该配置文件
可用来加载集群信息。
字段 描述
kubeConfigPath
[必需]
string
kubeConfigPath
用来指定一个文件或者 URL 路径,指向一个 kubeconfig 文件;
该配置文件可用来加载集群信息。
HostPathMount
出现在:
HostPathMount 包含从宿主节点挂载的卷的信息。
字段 描述
name
[必需]
string
name
为卷在 Pod 模板中的名称。
hostPath
[必需]
string
hostPath
是要在 Pod 中挂载的卷在宿主系统上的路径。
mountPath
[必需]
string
mountPath
是 hostPath
在 Pod 内挂载的路径。
readOnly
bool
readOnly
控制卷的读写访问模式。
pathType
core/v1.HostPathType
pathType
是 hostPath
的类型。
出现在:
ImageMeta 用来配置来源不是 Kubernetes/kubernetes
发布过程的组件所使用的镜像。
字段 描述
imageRepository
string
imageRepository
设置镜像拉取所用的容器仓库。
若未设置,则使用 ClusterConfiguration 中的 imageRepository
。
imageTag
string
imageTag
允许用户设置镜像的标签。
如果设置了此字段,则 kubeadm 不再在集群升级时自动更改组件的版本。
JoinControlPlane
出现在:
JoinControlPlane 包含在正在加入集群的节点上要部署的额外的控制面组件的
设置。
字段 描述
localAPIEndpoint
APIEndpoint
localAPIEndpoint
代表的是将在此节点上部署的 API 服务器实例
的端点。
certificateKey
string
certificateKey
是在添加新的控制面节点时用来解密所下载的
Secret 中的证书的秘钥。对应的加密秘钥在 InitConfiguration 结构中。
LocalEtcd
出现在:
LocalEtcd 描述的是 kubeadm 要使用的本地 etcd 集群。
字段 描述
ImageMeta
[必需]
ImageMeta
(ImageMeta
结构的字段被嵌入到此类型中。)
ImageMeta 允许用户为 etcd 定制要使用的容器。
dataDir
[必需]
string
dataDir
是 etcd 用来存放数据的目录。
默认值为 "/var/lib/etcd"。
extraArgs
map[string]string
extraArgs
是为 etcd 可执行文件提供的额外参数,用于在静态
Pod 中运行 etcd。映射中的每一个键对应命令行上的一个标志参数,只是去掉了
前置的连字符。
serverCertSANs
[]string
serverCertSANs
为 etcd 服务器的签名证书设置额外的
主体替代名(Subject Alternative Names,SAN)。
peerCertSANs
[]string
peerCertSANs
为 etcd 的对等端签名证书设置额外的
主体替代名(Subject Alternative Names,SAN)。
Networking
出现在:
Networking 中包含描述集群网络配置的元素。
字段 描述
serviceSubnet
string
serviceSubnet
是 Kubernetes 服务所使用的的子网。
默认值为 "10.96.0.0/12"。
podSubnet
string
podSubnet
为 Pod 所使用的子网。
dnsDomain
string
dnsDomain
是 Kubernetes 服务所使用的的 DNS 域名。
默认值为 "cluster.local"。
NodeRegistrationOptions
出现在:
NodeRegistrationOptions 包含向集群中注册新的控制面或节点所需要的信息;
节点注册可能通过 "kubeadm init" 或 "kubeadm join" 完成。
字段 描述
name
string
name
是 Node API 对象的 .metadata.name
字段值;
该 API 对象会在此 kubeadm init
或 kubeadm join
操作期间创建。
在提交给 API 服务器的 kubelet 客户端证书中,此字段也用作其 CommonName
。
如果未指定则默认为节点的主机名。
criSocket
string
criSocket
用来读取容器运行时的信息。
此信息会被以注解的方式添加到 Node API 对象至上,用于后续用途。
taints
[必需]
[]core/v1.Taint
tains
设定 Node API 对象被注册时要附带的污点。
若未设置此字段(即字段值为 null), 在 kubeadm init
期间,节点与控制面之间的通信。默认值为污点默认设置为 taints: ["node-role.kubernetes.io/master:""]
。
如果你不希望为控制面节点设置污点,可以在 YAML 中将此字段设置为空的列表,即
taints: []
。 此字段仅用在 Node 注册期间。
kubeletExtraArgs
map[string]string
kubeletExtraArgs
用来向 kubelet 传递额外参数。
这里的参数会通过 kubeadm 在运行时写入的、由 kubelet 来读取的环境文件来
传递给 kubelet 命令行。
这里的设置会覆盖掉 'kubelet-config-1.X' ConfigMap 中包含的一般性的配置。
命令行标志在解析时优先级更高。
这里的设置值仅作用于 kubeadm 运行所在的节点。
映射中的每个键对应命令行中的一个标志参数,只是去掉了前置的连字符。
ignorePreflightErrors
[]string
ignorePreflightErrors
提供一组在当前节点被注册时可以
忽略掉的预检错误。
imagePullPolicy
core/v1.PullPolicy
imagePullPolicy
设定 "kubeadm init" 和 "kubeadm join"
操作期间的镜像拉取策略。此字段的取值可以是 "Always"、"IfNotPresent" 或
"Never" 之一。
若此字段未设置,则 kubeadm 使用 "IfNotPresent" 作为其默认值,换言之,
当镜像在主机上不存在时才执行拉取操作。
Patches
出现在:
Patches 包含要向 kubeadm 所部署的组件应用的补丁信息。
字段 描述
directory
string
directory
是指向某目录的路径,该目录中包含名为
"target[suffix][+patchtype].extension" 的文件。
例如,"kube-apiserver0+merge.yaml" 或者 "etcd.json"。
"target" 可以是 "kube-apiserver"、"kube-controller-manager"、
"kube-scheduler"、"etcd" 之一。
"patchtype" 可以是 "strategic"、"merge" 或者 "json",
其取值对应 kubectl 所支持的补丁形式。
"patchtype" 的默认值是 "strategic"。
"extension" 必须是 "json" 或者 "yaml"。
"suffix" 是一个可选的字符串,用来确定按字母表顺序来应用时,哪个补丁最先被应用。
BootstrapToken
出现在:
BootstrapToken 描述的是一个启动引导令牌,以 Secret 形式存储在集群中。
字段 描述
token
[必需]
BootstrapTokenString
token
用来在节点与控制面之间建立双向的信任关系。
在向集群中添加节点时使用。
description
string
description
设置一个对人友好的消息,说明为什么此令牌
会存在以及其目标用途,这样其他管理员能够知道其目的。
ttl
meta/v1.Duration
ttl
定义此令牌的声明周期。默认为 24h
。
expires
和 ttl
是互斥的。
expires
meta/v1.Time
expires
设置此令牌过期的时间戳。默认为在运行时基于
ttl
来决定。
expires
和 ttl
是互斥的。
usages
[]string
usages
描述此令牌的可能使用方式。默认情况下,令牌可用于
建立双向的信任关系;不过这里可以改变默认用途。
groups
[]string
groups
设定此令牌被用于身份认证时对应的附加用户组。
BootstrapTokenString
出现在:
BootstrapTokenString 形式为 abcdef.abcdef0123456789
的一个令牌,
用来从加入集群的节点角度验证 API 服务器的身份,或者 "kubeadm join"
在节点启动引导是作为一种身份认证方法。
此令牌的生命期是短暂的,并且应该如此。
字段 描述
id
[必需]
string
无描述
secret
[必需]
string
无描述
12.11 - Kubelet Configuration (v1beta1)
Resource Types
KubeletConfiguration
KubeletConfiguration contains the configuration for the Kubelet
Field Description
apiVersion
stringkubelet.config.k8s.io/v1beta1
kind
stringKubeletConfiguration
enableServer
[Required]
bool
enableServer enables Kubelet's secured server.
Note: Kubelet's insecure port is controlled by the readOnlyPort option.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may disrupt components that interact with the Kubelet server.
Default: true
staticPodPath
string
staticPodPath is the path to the directory containing local (static) pods to
run, or the path to a single static pod file.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
the set of static pods specified at the new path may be different than the
ones the Kubelet initially started with, and this may disrupt your node.
Default: ""
syncFrequency
meta/v1.Duration
syncFrequency is the max period between synchronizing running
containers and config.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
shortening this duration may have a negative performance impact, especially
as the number of Pods on the node increases. Alternatively, increasing this
duration will result in longer refresh times for ConfigMaps and Secrets.
Default: "1m"
fileCheckFrequency
meta/v1.Duration
fileCheckFrequency is the duration between checking config files for
new data
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
shortening the duration will cause the Kubelet to reload local Static Pod
configurations more frequently, which may have a negative performance impact.
Default: "20s"
httpCheckFrequency
meta/v1.Duration
httpCheckFrequency is the duration between checking http for new data
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
shortening the duration will cause the Kubelet to poll staticPodURL more
frequently, which may have a negative performance impact.
Default: "20s"
staticPodURL
string
staticPodURL is the URL for accessing static pods to run
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
the set of static pods specified at the new URL may be different than the
ones the Kubelet initially started with, and this may disrupt your node.
Default: ""
staticPodURLHeader
map[string][]string
staticPodURLHeader is a map of slices with HTTP headers to use when accessing the podURL
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may disrupt the ability to read the latest set of static pods from StaticPodURL.
Default: nil
address
string
address is the IP address for the Kubelet to serve on (set to 0.0.0.0
for all interfaces).
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may disrupt components that interact with the Kubelet server.
Default: "0.0.0.0"
port
int32
port is the port for the Kubelet to serve on.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may disrupt components that interact with the Kubelet server.
Default: 10250
readOnlyPort
int32
readOnlyPort is the read-only port for the Kubelet to serve on with
no authentication/authorization.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may disrupt components that interact with the Kubelet server.
Default: 0 (disabled)
tlsCertFile
string
tlsCertFile is the file containing x509 Certificate for HTTPS. (CA cert,
if any, concatenated after server cert). If tlsCertFile and
tlsPrivateKeyFile are not provided, a self-signed certificate
and key are generated for the public address and saved to the directory
passed to the Kubelet's --cert-dir flag.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may disrupt components that interact with the Kubelet server.
Default: ""
tlsPrivateKeyFile
string
tlsPrivateKeyFile is the file containing x509 private key matching tlsCertFile
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may disrupt components that interact with the Kubelet server.
Default: ""
tlsCipherSuites
[]string
TLSCipherSuites is the list of allowed cipher suites for the server.
Values are from tls package constants (https://golang.org/pkg/crypto/tls/#pkg-constants).
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may disrupt components that interact with the Kubelet server.
Default: nil
tlsMinVersion
string
TLSMinVersion is the minimum TLS version supported.
Values are from tls package constants (https://golang.org/pkg/crypto/tls/#pkg-constants).
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may disrupt components that interact with the Kubelet server.
Default: ""
rotateCertificates
bool
rotateCertificates enables client certificate rotation. The Kubelet will request a
new certificate from the certificates.k8s.io API. This requires an approver to approve the
certificate signing requests.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
disabling it may disrupt the Kubelet's ability to authenticate with the API server
after the current certificate expires.
Default: false
serverTLSBootstrap
bool
serverTLSBootstrap enables server certificate bootstrap. Instead of self
signing a serving certificate, the Kubelet will request a certificate from
the certificates.k8s.io API. This requires an approver to approve the
certificate signing requests. The RotateKubeletServerCertificate feature
must be enabled.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
disabling it will stop the renewal of Kubelet server certificates, which can
disrupt components that interact with the Kubelet server in the long term,
due to certificate expiration.
Default: false
authentication
KubeletAuthentication
authentication specifies how requests to the Kubelet's server are authenticated
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may disrupt components that interact with the Kubelet server.
Defaults:
anonymous:
enabled: false
webhook:
enabled: true
cacheTTL: "2m"
authorization
KubeletAuthorization
authorization specifies how requests to the Kubelet's server are authorized
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may disrupt components that interact with the Kubelet server.
Defaults:
mode: Webhook
webhook:
cacheAuthorizedTTL: "5m"
cacheUnauthorizedTTL: "30s"
registryPullQPS
int32
registryPullQPS is the limit of registry pulls per second.
Set to 0 for no limit.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may impact scalability by changing the amount of traffic produced
by image pulls.
Default: 5
registryBurst
int32
registryBurst is the maximum size of bursty pulls, temporarily allows
pulls to burst to this number, while still not exceeding registryPullQPS.
Only used if registryPullQPS > 0.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may impact scalability by changing the amount of traffic produced
by image pulls.
Default: 10
eventRecordQPS
int32
eventRecordQPS is the maximum event creations per second. If 0, there
is no limit enforced.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may impact scalability by changing the amount of traffic produced by
event creations.
Default: 5
eventBurst
int32
eventBurst is the maximum size of a burst of event creations, temporarily
allows event creations to burst to this number, while still not exceeding
eventRecordQPS. Only used if eventRecordQPS > 0.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may impact scalability by changing the amount of traffic produced by
event creations.
Default: 10
enableDebuggingHandlers
bool
enableDebuggingHandlers enables server endpoints for log access
and local running of containers and commands, including the exec,
attach, logs, and portforward features.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
disabling it may disrupt components that interact with the Kubelet server.
Default: true
enableContentionProfiling
bool
enableContentionProfiling enables lock contention profiling, if enableDebuggingHandlers is true.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
enabling it may carry a performance impact.
Default: false
healthzPort
int32
healthzPort is the port of the localhost healthz endpoint (set to 0 to disable)
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may disrupt components that monitor Kubelet health.
Default: 10248
healthzBindAddress
string
healthzBindAddress is the IP address for the healthz server to serve on
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may disrupt components that monitor Kubelet health.
Default: "127.0.0.1"
oomScoreAdj
int32
oomScoreAdj is The oom-score-adj value for kubelet process. Values
must be within the range [-1000, 1000].
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may impact the stability of nodes under memory pressure.
Default: -999
clusterDomain
string
clusterDomain is the DNS domain for this cluster. If set, kubelet will
configure all containers to search this domain in addition to the
host's search domains.
Dynamic Kubelet Config (beta): Dynamically updating this field is not recommended,
as it should be kept in sync with the rest of the cluster.
Default: ""
clusterDNS
[]string
clusterDNS is a list of IP addresses for the cluster DNS server. If set,
kubelet will configure all containers to use this for DNS resolution
instead of the host's DNS servers.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
changes will only take effect on Pods created after the update. Draining
the node is recommended before changing this field.
Default: nil
streamingConnectionIdleTimeout
meta/v1.Duration
streamingConnectionIdleTimeout is the maximum time a streaming connection
can be idle before the connection is automatically closed.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may impact components that rely on infrequent updates over streaming
connections to the Kubelet server.
Default: "4h"
nodeStatusUpdateFrequency
meta/v1.Duration
nodeStatusUpdateFrequency is the frequency that kubelet computes node
status. If node lease feature is not enabled, it is also the frequency that
kubelet posts node status to master.
Note: When node lease feature is not enabled, be cautious when changing the
constant, it must work with nodeMonitorGracePeriod in nodecontroller.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may impact node scalability, and also that the node controller's
nodeMonitorGracePeriod must be set to N∗NodeStatusUpdateFrequency,
where N is the number of retries before the node controller marks
the node unhealthy.
Default: "10s"
nodeStatusReportFrequency
meta/v1.Duration
nodeStatusReportFrequency is the frequency that kubelet posts node
status to master if node status does not change. Kubelet will ignore this
frequency and post node status immediately if any change is detected. It is
only used when node lease feature is enabled. nodeStatusReportFrequency's
default value is 1m. But if nodeStatusUpdateFrequency is set explicitly,
nodeStatusReportFrequency's default value will be set to
nodeStatusUpdateFrequency for backward compatibility.
Default: "1m"
nodeLeaseDurationSeconds
int32
nodeLeaseDurationSeconds is the duration the Kubelet will set on its corresponding Lease,
when the NodeLease feature is enabled. This feature provides an indicator of node
health by having the Kubelet create and periodically renew a lease, named after the node,
in the kube-node-lease namespace. If the lease expires, the node can be considered unhealthy.
The lease is currently renewed every 10s, per KEP-0009. In the future, the lease renewal interval
may be set based on the lease duration.
Requires the NodeLease feature gate to be enabled.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
decreasing the duration may reduce tolerance for issues that temporarily prevent
the Kubelet from renewing the lease (e.g. a short-lived network issue).
Default: 40
imageMinimumGCAge
meta/v1.Duration
imageMinimumGCAge is the minimum age for an unused image before it is
garbage collected.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may trigger or delay garbage collection, and may change the image overhead
on the node.
Default: "2m"
imageGCHighThresholdPercent
int32
imageGCHighThresholdPercent is the percent of disk usage after which
image garbage collection is always run. The percent is calculated as
this field value out of 100.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may trigger or delay garbage collection, and may change the image overhead
on the node.
Default: 85
imageGCLowThresholdPercent
int32
imageGCLowThresholdPercent is the percent of disk usage before which
image garbage collection is never run. Lowest disk usage to garbage
collect to. The percent is calculated as this field value out of 100.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may trigger or delay garbage collection, and may change the image overhead
on the node.
Default: 80
volumeStatsAggPeriod
meta/v1.Duration
How frequently to calculate and cache volume disk usage for all pods
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
shortening the period may carry a performance impact.
Default: "1m"
kubeletCgroups
string
kubeletCgroups is the absolute name of cgroups to isolate the kubelet in
Dynamic Kubelet Config (beta): This field should not be updated without a full node
reboot. It is safest to keep this value the same as the local config.
Default: ""
systemCgroups
string
systemCgroups is absolute name of cgroups in which to place
all non-kernel processes that are not already in a container. Empty
for no container. Rolling back the flag requires a reboot.
Dynamic Kubelet Config (beta): This field should not be updated without a full node
reboot. It is safest to keep this value the same as the local config.
Default: ""
cgroupRoot
string
cgroupRoot is the root cgroup to use for pods. This is handled by the
container runtime on a best effort basis.
Dynamic Kubelet Config (beta): This field should not be updated without a full node
reboot. It is safest to keep this value the same as the local config.
Default: ""
cgroupsPerQOS
bool
Enable QoS based Cgroup hierarchy: top level cgroups for QoS Classes
And all Burstable and BestEffort pods are brought up under their
specific top level QoS cgroup.
Dynamic Kubelet Config (beta): This field should not be updated without a full node
reboot. It is safest to keep this value the same as the local config.
Default: true
cgroupDriver
string
driver that the kubelet uses to manipulate cgroups on the host (cgroupfs or systemd)
Dynamic Kubelet Config (beta): This field should not be updated without a full node
reboot. It is safest to keep this value the same as the local config.
Default: "cgroupfs"
cpuManagerPolicy
string
CPUManagerPolicy is the name of the policy to use.
Requires the CPUManager feature gate to be enabled.
Dynamic Kubelet Config (beta): This field should not be updated without a full node
reboot. It is safest to keep this value the same as the local config.
Default: "none"
cpuManagerReconcilePeriod
meta/v1.Duration
CPU Manager reconciliation period.
Requires the CPUManager feature gate to be enabled.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
shortening the period may carry a performance impact.
Default: "10s"
topologyManagerPolicy
string
TopologyManagerPolicy is the name of the policy to use.
Policies other than "none" require the TopologyManager feature gate to be enabled.
Dynamic Kubelet Config (beta): This field should not be updated without a full node
reboot. It is safest to keep this value the same as the local config.
Default: "none"
topologyManagerScope
string
TopologyManagerScope represents the scope of topology hint generation
that topology manager requests and hint providers generate.
"pod" scope requires the TopologyManager feature gate to be enabled.
Default: "container"
qosReserved
map[string]string
qosReserved is a set of resource name to percentage pairs that specify
the minimum percentage of a resource reserved for exclusive use by the
guaranteed QoS tier.
Currently supported resources: "memory"
Requires the QOSReserved feature gate to be enabled.
Dynamic Kubelet Config (beta): This field should not be updated without a full node
reboot. It is safest to keep this value the same as the local config.
Default: nil
runtimeRequestTimeout
meta/v1.Duration
runtimeRequestTimeout is the timeout for all runtime requests except long running
requests - pull, logs, exec and attach.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may disrupt components that interact with the Kubelet server.
Default: "2m"
hairpinMode
string
hairpinMode specifies how the Kubelet should configure the container
bridge for hairpin packets.
Setting this flag allows endpoints in a Service to loadbalance back to
themselves if they should try to access their own Service. Values:
"promiscuous-bridge": make the container bridge promiscuous.
"hairpin-veth": set the hairpin flag on container veth interfaces.
"none": do nothing.
Generally, one must set --hairpin-mode=hairpin-veth to achieve hairpin NAT,
because promiscuous-bridge assumes the existence of a container bridge named cbr0.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may require a node reboot, depending on the network plugin.
Default: "promiscuous-bridge"
maxPods
int32
maxPods is the number of pods that can run on this Kubelet.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
changes may cause Pods to fail admission on Kubelet restart, and may change
the value reported in Node.Status.Capacity[v1.ResourcePods], thus affecting
future scheduling decisions. Increasing this value may also decrease performance,
as more Pods can be packed into a single node.
Default: 110
podCIDR
string
The CIDR to use for pod IP addresses, only used in standalone mode.
In cluster mode, this is obtained from the master.
Dynamic Kubelet Config (beta): This field should always be set to the empty default.
It should only set for standalone Kubelets, which cannot use Dynamic Kubelet Config.
Default: ""
podPidsLimit
int64
PodPidsLimit is the maximum number of pids in any pod.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
lowering it may prevent container processes from forking after the change.
Default: -1
resolvConf
string
ResolverConfig is the resolver configuration file used as the basis
for the container DNS resolution configuration.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
changes will only take effect on Pods created after the update. Draining
the node is recommended before changing this field.
Default: "/etc/resolv.conf"
runOnce
bool
RunOnce causes the Kubelet to check the API server once for pods,
run those in addition to the pods specified by static pod files, and exit.
Default: false
cpuCFSQuota
bool
cpuCFSQuota enables CPU CFS quota enforcement for containers that
specify CPU limits.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
disabling it may reduce node stability.
Default: true
cpuCFSQuotaPeriod
meta/v1.Duration
CPUCFSQuotaPeriod is the CPU CFS quota period value, cpu.cfs_period_us.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
limits set for containers will result in different cpu.cfs_quota settings. This
will trigger container restarts on the node being reconfigured.
Default: "100ms"
nodeStatusMaxImages
int32
nodeStatusMaxImages caps the number of images reported in Node.Status.Images.
Note: If -1 is specified, no cap will be applied. If 0 is specified, no image is returned.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
different values can be reported on node status.
Default: 50
maxOpenFiles
int64
maxOpenFiles is Number of files that can be opened by Kubelet process.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may impact the ability of the Kubelet to interact with the node's filesystem.
Default: 1000000
contentType
string
contentType is contentType of requests sent to apiserver.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may impact the ability for the Kubelet to communicate with the API server.
If the Kubelet loses contact with the API server due to a change to this field,
the change cannot be reverted via dynamic Kubelet config.
Default: "application/vnd.kubernetes.protobuf"
kubeAPIQPS
int32
kubeAPIQPS is the QPS to use while talking with kubernetes apiserver
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may impact scalability by changing the amount of traffic the Kubelet
sends to the API server.
Default: 5
kubeAPIBurst
int32
kubeAPIBurst is the burst to allow while talking with kubernetes apiserver
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may impact scalability by changing the amount of traffic the Kubelet
sends to the API server.
Default: 10
serializeImagePulls
bool
serializeImagePulls when enabled, tells the Kubelet to pull images one
at a time. We recommend ∗not∗ changing the default value on nodes that
run docker daemon with version < 1.9 or an Aufs storage backend.
Issue #10959 has more details.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may impact the performance of image pulls.
Default: true
evictionHard
map[string]string
Map of signal names to quantities that defines hard eviction thresholds. For example: {"memory.available": "300Mi"}.
To explicitly disable, pass a 0% or 100% threshold on an arbitrary resource.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may trigger or delay Pod evictions.
Default:
memory.available: "100Mi"
nodefs.available: "10%"
nodefs.inodesFree: "5%"
imagefs.available: "15%"
evictionSoft
map[string]string
Map of signal names to quantities that defines soft eviction thresholds.
For example: {"memory.available": "300Mi"}.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may trigger or delay Pod evictions, and may change the allocatable reported
by the node.
Default: nil
evictionSoftGracePeriod
map[string]string
Map of signal names to quantities that defines grace periods for each soft eviction signal.
For example: {"memory.available": "30s"}.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may trigger or delay Pod evictions.
Default: nil
evictionPressureTransitionPeriod
meta/v1.Duration
Duration for which the kubelet has to wait before transitioning out of an eviction pressure condition.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
lowering it may decrease the stability of the node when the node is overcommitted.
Default: "5m"
evictionMaxPodGracePeriod
int32
Maximum allowed grace period (in seconds) to use when terminating pods in
response to a soft eviction threshold being met. This value effectively caps
the Pod's TerminationGracePeriodSeconds value during soft evictions.
Note: Due to issue #64530, the behavior has a bug where this value currently just
overrides the grace period during soft eviction, which can increase the grace
period from what is set on the Pod. This bug will be fixed in a future release.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
lowering it decreases the amount of time Pods will have to gracefully clean
up before being killed during a soft eviction.
Default: 0
evictionMinimumReclaim
map[string]string
Map of signal names to quantities that defines minimum reclaims, which describe the minimum
amount of a given resource the kubelet will reclaim when performing a pod eviction while
that resource is under pressure. For example: {"imagefs.available": "2Gi"}
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may change how well eviction can manage resource pressure.
Default: nil
podsPerCore
int32
podsPerCore is the maximum number of pods per core. Cannot exceed MaxPods.
If 0, this field is ignored.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
changes may cause Pods to fail admission on Kubelet restart, and may change
the value reported in Node.Status.Capacity[v1.ResourcePods], thus affecting
future scheduling decisions. Increasing this value may also decrease performance,
as more Pods can be packed into a single node.
Default: 0
enableControllerAttachDetach
bool
enableControllerAttachDetach enables the Attach/Detach controller to
manage attachment/detachment of volumes scheduled to this node, and
disables kubelet from executing any attach/detach operations
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
changing which component is responsible for volume management on a live node
may result in volumes refusing to detach if the node is not drained prior to
the update, and if Pods are scheduled to the node before the
volumes.kubernetes.io/controller-managed-attach-detach annotation is updated by the
Kubelet. In general, it is safest to leave this value set the same as local config.
Default: true
protectKernelDefaults
bool
protectKernelDefaults, if true, causes the Kubelet to error if kernel
flags are not as it expects. Otherwise the Kubelet will attempt to modify
kernel flags to match its expectation.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
enabling it may cause the Kubelet to crash-loop if the Kernel is not configured as
Kubelet expects.
Default: false
makeIPTablesUtilChains
bool
If true, Kubelet ensures a set of iptables rules are present on host.
These rules will serve as utility rules for various components, e.g. KubeProxy.
The rules will be created based on IPTablesMasqueradeBit and IPTablesDropBit.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
disabling it will prevent the Kubelet from healing locally misconfigured iptables rules.
Default: true
iptablesMasqueradeBit
int32
iptablesMasqueradeBit is the bit of the iptables fwmark space to mark for SNAT
Values must be within the range [0, 31]. Must be different from other mark bits.
Warning: Please match the value of the corresponding parameter in kube-proxy.
TODO: clean up IPTablesMasqueradeBit in kube-proxy
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it needs to be coordinated with other components, like kube-proxy, and the update
will only be effective if MakeIPTablesUtilChains is enabled.
Default: 14
iptablesDropBit
int32
iptablesDropBit is the bit of the iptables fwmark space to mark for dropping packets.
Values must be within the range [0, 31]. Must be different from other mark bits.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it needs to be coordinated with other components, like kube-proxy, and the update
will only be effective if MakeIPTablesUtilChains is enabled.
Default: 15
featureGates
map[string]bool
featureGates is a map of feature names to bools that enable or disable alpha/experimental
features. This field modifies piecemeal the built-in default values from
"k8s.io/kubernetes/pkg/features/kube_features.go".
Dynamic Kubelet Config (beta): If dynamically updating this field, consider the
documentation for the features you are enabling or disabling. While we
encourage feature developers to make it possible to dynamically enable
and disable features, some changes may require node reboots, and some
features may require careful coordination to retroactively disable.
Default: nil
failSwapOn
bool
failSwapOn tells the Kubelet to fail to start if swap is enabled on the node.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
setting it to true will cause the Kubelet to crash-loop if swap is enabled.
Default: true
containerLogMaxSize
string
A quantity defines the maximum size of the container log file before it is rotated.
For example: "5Mi" or "256Ki".
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may trigger log rotation.
Default: "10Mi"
containerLogMaxFiles
int32
Maximum number of container log files that can be present for a container.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
lowering it may cause log files to be deleted.
Default: 5
configMapAndSecretChangeDetectionStrategy
ResourceChangeDetectionStrategy
ConfigMapAndSecretChangeDetectionStrategy is a mode in which
config map and secret managers are running.
Default: "Watch"
systemReserved
map[string]string
systemReserved is a set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=150G)
pairs that describe resources reserved for non-kubernetes components.
Currently only cpu and memory are supported.
See http://kubernetes.io/docs/user-guide/compute-resources for more detail.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may not be possible to increase the reserved resources, because this
requires resizing cgroups. Always look for a NodeAllocatableEnforced event
after updating this field to ensure that the update was successful.
Default: nil
kubeReserved
map[string]string
A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=150G) pairs
that describe resources reserved for kubernetes system components.
Currently cpu, memory and local storage for root file system are supported.
See http://kubernetes.io/docs/user-guide/compute-resources for more detail.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may not be possible to increase the reserved resources, because this
requires resizing cgroups. Always look for a NodeAllocatableEnforced event
after updating this field to ensure that the update was successful.
Default: nil
reservedSystemCPUs
[Required]
string
This ReservedSystemCPUs option specifies the cpu list reserved for the host level system threads and kubernetes related threads.
This provide a "static" CPU list rather than the "dynamic" list by system-reserved and kube-reserved.
This option overwrites CPUs provided by system-reserved and kube-reserved.
showHiddenMetricsForVersion
string
The previous version for which you want to show hidden metrics.
Only the previous minor version is meaningful, other values will not be allowed.
The format is ., e.g.: '1.16'.
The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics,
rather than being surprised when they are permanently removed in the release after that.
Default: ""
systemReservedCgroup
string
This flag helps kubelet identify absolute name of top level cgroup used to enforce `SystemReserved` compute resource reservation for OS system daemons.
Refer to [Node Allocatable](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md) doc for more information.
Dynamic Kubelet Config (beta): This field should not be updated without a full node
reboot. It is safest to keep this value the same as the local config.
Default: ""
kubeReservedCgroup
string
This flag helps kubelet identify absolute name of top level cgroup used to enforce `KubeReserved` compute resource reservation for Kubernetes node system daemons.
Refer to [Node Allocatable](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md) doc for more information.
Dynamic Kubelet Config (beta): This field should not be updated without a full node
reboot. It is safest to keep this value the same as the local config.
Default: ""
enforceNodeAllocatable
[]string
This flag specifies the various Node Allocatable enforcements that Kubelet needs to perform.
This flag accepts a list of options. Acceptable options are `none`, `pods`, `system-reserved` & `kube-reserved`.
If `none` is specified, no other options may be specified.
Refer to [Node Allocatable](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md) doc for more information.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
removing enforcements may reduce the stability of the node. Alternatively, adding
enforcements may reduce the stability of components which were using more than
the reserved amount of resources; for example, enforcing kube-reserved may cause
Kubelets to OOM if it uses more than the reserved resources, and enforcing system-reserved
may cause system daemons to OOM if they use more than the reserved resources.
Default: ["pods"]
allowedUnsafeSysctls
[]string
A comma separated whitelist of unsafe sysctls or sysctl patterns (ending in ∗).
Unsafe sysctl groups are kernel.shm∗, kernel.msg∗, kernel.sem, fs.mqueue.∗, and net.∗.
These sysctls are namespaced but not allowed by default. For example: "kernel.msg∗,net.ipv4.route.min_pmtu"
Default: []
volumePluginDir
string
volumePluginDir is the full path of the directory in which to search
for additional third party volume plugins.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that changing
the volumePluginDir may disrupt workloads relying on third party volume plugins.
Default: "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/"
providerID
string
providerID, if set, sets the unique id of the instance that an external provider (i.e. cloudprovider)
can use to identify a specific node.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may impact the ability of the Kubelet to interact with cloud providers.
Default: ""
kernelMemcgNotification
bool
kernelMemcgNotification, if set, the kubelet will integrate with the kernel memcg notification
to determine if memory eviction thresholds are crossed rather than polling.
Dynamic Kubelet Config (beta): If dynamically updating this field, consider that
it may impact the way Kubelet interacts with the kernel.
Default: false
logging
[Required]
LoggingConfiguration
Logging specifies the options of logging.
Refer [Logs Options](https://github.com/kubernetes/component-base/blob/master/logs/options.go) for more information.
Defaults:
Format: text
enableSystemLogHandler
bool
enableSystemLogHandler enables system logs via web interface host:port/logs/
Default: true
shutdownGracePeriod
meta/v1.Duration
ShutdownGracePeriod specifies the total duration that the node should delay the shutdown and total grace period for pod termination during a node shutdown.
Default: "30s"
shutdownGracePeriodCriticalPods
meta/v1.Duration
ShutdownGracePeriodCriticalPods specifies the duration used to terminate critical pods during a node shutdown. This should be less than ShutdownGracePeriod.
For example, if ShutdownGracePeriod=30s, and ShutdownGracePeriodCriticalPods=10s, during a node shutdown the first 20 seconds would be reserved for gracefully terminating normal pods, and the last 10 seconds would be reserved for terminating critical pods.
Default: "10s"
SerializedNodeConfigSource
SerializedNodeConfigSource allows us to serialize v1.NodeConfigSource.
This type is used internally by the Kubelet for tracking checkpointed dynamic configs.
It exists in the kubeletconfig API group because it is classified as a versioned input to the Kubelet.
Field Description
apiVersion
stringkubelet.config.k8s.io/v1beta1
kind
stringSerializedNodeConfigSource
source
core/v1.NodeConfigSource
Source is the source that we are serializing
HairpinMode
(Alias of string
)
HairpinMode denotes how the kubelet should configure networking to handle
hairpin packets.
KubeletAnonymousAuthentication
Appears in:
Field Description
enabled
bool
enabled allows anonymous requests to the kubelet server.
Requests that are not rejected by another authentication method are treated as anonymous requests.
Anonymous requests have a username of system:anonymous, and a group name of system:unauthenticated.
KubeletAuthentication
Appears in:
KubeletAuthorization
Appears in:
Field Description
mode
KubeletAuthorizationMode
mode is the authorization mode to apply to requests to the kubelet server.
Valid values are AlwaysAllow and Webhook.
Webhook mode uses the SubjectAccessReview API to determine authorization.
webhook
KubeletWebhookAuthorization
webhook contains settings related to Webhook authorization.
KubeletAuthorizationMode
(Alias of string
)
Appears in:
KubeletWebhookAuthentication
Appears in:
Field Description
enabled
bool
enabled allows bearer token authentication backed by the tokenreviews.authentication.k8s.io API
cacheTTL
meta/v1.Duration
cacheTTL enables caching of authentication results
KubeletWebhookAuthorization
Appears in:
Field Description
cacheAuthorizedTTL
meta/v1.Duration
cacheAuthorizedTTL is the duration to cache 'authorized' responses from the webhook authorizer.
cacheUnauthorizedTTL
meta/v1.Duration
cacheUnauthorizedTTL is the duration to cache 'unauthorized' responses from the webhook authorizer.
KubeletX509Authentication
Appears in:
Field Description
clientCAFile
string
clientCAFile is the path to a PEM-encoded certificate bundle. If set, any request presenting a client certificate
signed by one of the authorities in the bundle is authenticated with a username corresponding to the CommonName,
and groups corresponding to the Organization in the client certificate.
ResourceChangeDetectionStrategy
(Alias of string
)
Appears in:
ResourceChangeDetectionStrategy denotes a mode in which internal
managers (secret, configmap) are discovering object changes.
LoggingConfiguration
Appears in:
LoggingConfiguration contains logging options
Refer Logs Options for more information.
Field Description
format
[Required]
string
Format Flag specifies the structure of log messages.
default value of format is `text`
sanitization
[Required]
bool
[Experimental] When enabled prevents logging of fields tagged as sensitive (passwords, keys, tokens).
Runtime log sanitization may introduce significant computation overhead and therefore should not be enabled in production.`)
12.12 - Kubelet 配置 (v1alpha1)
资源类型
出现在:
FormatOptions 包含为不同类型日志格式提供的选项。
字段 描述
json
[必需]
JSONOptions
[试验特性] json
中包含 "json" 日志格式的选项。
JSONOptions
出现在:
JSONOptions 包含用于 "json" 日志格式的选项。
字段 描述
splitStream
[必需]
bool
[试验特性] splitStream
将错误信息重定向到标准错误输出(stderr),
将提示信息重定向到标准输出(stdout),并为二者提供缓存。默认配置是将两类信息都写出到标准输出,
并且不提供缓存。
infoBufferSize
[必需]
k8s.io/apimachinery/pkg/api/resource.QuantityValue
[试验特性] infoBufferSize
设置使用分离数据流时信息数据流的大小。
默认值是 0,意味着禁止缓存。
VModuleConfiguration
([]k8s.io/component-base/config/v1alpha1.VModuleItem
的别名)
出现在:
VModuleConfiguration 是一个集合,其中包含一个个的文件名(或者文件名模式)
及对应的详细程度阈值。
CredentialProviderConfig
CredentialProviderConfig 包含有关每个 exec 凭据提供者的配置信息。
Kubelet 从磁盘上读取这些配置信息,并根据 CredentialProvider 类型启用各个提供者。
字段 描述
apiVersion
stringkubelet.config.k8s.io/v1alpha1
kind
stringCredentialProviderConfig
providers
[必需]
[]CredentialProvider
providers
是一组凭据提供者插件,这些插件会被 kubelet 启用。
多个提供者可以匹配到同一镜像上,这时,来自所有提供者的凭据信息都会返回给 kubelet。
如果针对同一镜像调用了多个提供者,则结果会被组合起来。如果提供者返回的认证主键有重复,
列表中先出现的提供者所返回的值将被使用。
CredentialProvider
出现在:
CredentialProvider 代表的是要被 kubelet 调用的一个 exec 插件。
这一插件只会在所拉取的镜像与该插件所处理的镜像匹配时才会被调用(参见 matchImages
)。
字段 描述
name
[必需]
string
name
是凭据提供者的名称(必需)。此名称必须与 kubelet
所看到的提供者可执行文件的名称匹配。可执行文件必须位于 kubelet 的
bin
目录(通过 --image-credential-provider-bin-dir
设置)下。
matchImages
[必需]
[]string
matchImages
是一个必须设置的字符串列表,用来匹配镜像以便确定是否要调用此提供者。
如果字符串之一与 kubelet 所请求的镜像匹配,则此插件会被调用并给予提供凭证的机会。
镜像应该包含镜像库域名和 URL 路径。
matchImages
中的每个条目都是一个模式字符串,其中可以包含端口号和路径。
域名部分可以包含统配符,但端口或路径部分不可以。通配符可以用作子域名,例如
'∗.k8s.io' 或 'k8s.∗.io',以及顶级域名,如 'k8s.∗'。
对类似 'app∗.k8s.io' 这类部分子域名的匹配也是支持的。
每个通配符只能用来匹配一个子域名段,所以 '∗.io' 不会匹配 '∗.k8s.io'。
镜像与 matchImages
之间存在匹配时,以下条件都要满足:
二者均包含相同个数的域名部分,并且每个域名部分都对应匹配;
matchImages
条目中的 URL 路径部分必须是目标镜像的 URL 路径的前缀;
如果 matchImages
条目中包含端口号,则端口号也必须与镜像端口号匹配。
matchImages
的一些示例如下:
123456789.dkr.ecr.us-east-1.amazonaws.com
∗.azurecr.io
gcr.io
∗.∗.registry.io
registry.io:8080/path
defaultCacheDuration
[必需]
meta/v1.Duration
defaultCacheDuration
是插件在内存中缓存凭据的默认时长,
在插件响应中没有给出缓存时长时,使用这里设置的值。此字段是必需的。
apiVersion
[必需]
string
要求 exec 插件 CredentialProviderRequest 请求的输入版本。
所返回的 CredentialProviderResponse 必须使用与输入相同的编码版本。当前支持的值有:
credentialprovider.kubelet.k8s.io/v1alpha1
args
[]string
在执行插件可执行文件时要传递给命令的参数。
env
[]ExecEnvVar
env
定义要提供给插件进程的额外的环境变量。
这些环境变量会与主机上的其他环境变量以及 client-go 所使用的环境变量组合起来,
一起传递给插件。
ExecEnvVar
出现在:
ExecEnvVar 用来在执行基于 exec 的凭据插件时设置环境变量。
字段 描述
name
[必需]
string
环境变量名称。
value
[必需]
string
环境变量取值。
12.13 - WebhookAdmission 配置 (v1)
此 API 的版本是 v1。
资源类型
WebhookAdmission
WebhookAdmission 为 Webhook 准入控制器提供配置信息。
字段 描述
apiVersion
stringapiserver.config.k8s.io/v1
kind
stringWebhookAdmission
kubeConfigFile
[必需]
string
字段 kubeConfigFile 包含指向 kubeconfig 文件的路径。
12.14 - 客户端身份认证(Client Authentication) (v1)
资源类型
ExecCredential
ExecCredential 由基于 exec 的插件使用,与 HTTP 传输组件沟通凭据信息。
字段 描述
apiVersion
stringclient.authentication.k8s.io/v1
kind
stringExecCredential
spec
[必需]
ExecCredentialSpec
字段 spec 包含由 HTTP 传输组件传递给插件的信息。
status
ExecCredentialStatus
字段 status 由插件填充,包含传输组件与 API 服务器连接时需要提供的凭据。
Cluster
出现在:
Cluster 中包含允许 exec 插件与 Kubernetes 集群进行通信身份认证时所需
的信息。
字段 描述
server
[必需]
string
字段 server 是 Kubernetes 集群的地址(https://hostname:port)。
tls-server-name
string
tls-server-name 是用来提供给服务器用作 SNI 解析的,客户端以此检查服务器的证书。
如此字段为空,则使用链接服务器时使用的主机名。
insecure-skip-tls-verify
bool
设置此字段之后,会令客户端跳过对服务器端证书的合法性检查。
这会使得你的 HTTPS 链接不再安全。
certificate-authority-data
[]byte
此字段包含 PEM 编码的证书机构(CA)证书。
如果为空,则使用系统的根证书。
proxy-url
string
此字段用来设置向集群发送所有请求时要使用的代理服务器。
config
k8s.io/apimachinery/pkg/runtime.RawExtension
在某些环境中,用户配置可能对很多集群而言都完全一样(即调用同一个 exec 插件),
只是针对不同集群会有一些细节上的差异,例如 audience。
此字段使得特定于集群的配置可以直接使用集群信息来设置。
不建议使用此字段来保存 Secret 数据,因为 exec 插件的主要优势之一是不需要在
kubeconfig 中保存 Secret 数据。
ExecCredentialSpec
出现在:
ExecCredentialSpec 保存传输组件所提供的特定于请求和运行时的信息。
字段 描述
cluster
Cluster
此字段中包含的信息使得 exec 插件能够与要访问的 Kubernetes 集群通信。
注意,cluster 字段只有在 exec 驱动的配置中 provideClusterInfo
(即:ExecConfig.ProvideClusterInfo)被设置为 true 时才不能为空。
interactive
[必需]
bool
此字段用来标明标准输出信息是否已传递给 exec 插件。
ExecCredentialStatus
ExecCredentialStatus 中包含传输组件要使用的凭据。
字段 token 和 clientKeyData 都是敏感字段。此数据只能在
客户端与 exec 插件进程之间使用内存来传递。exec 插件本身至少
应通过文件访问许可来实施保护。
》
字段 描述
expirationTimestamp
meta/v1.Time
给出所提供的凭据到期的时间。
token
[必需]
string
客户端用做请求身份认证的持有者令牌。
clientCertificateData
[必需]
string
PEM 编码的客户端 TLS 证书(如果有临时证书,也会包含)。
clientKeyData
[必需]
string
与上述证书对应的、PEM 编码的私钥。
13 - 调度
13.1 - 调度器配置
FEATURE STATE: Kubernetes v1.19 [beta]
你可以通过编写配置文件,并将其路径传给 kube-scheduler
的命令行参数,定制 kube-scheduler
的行为。
调度模板(Profile)允许你配置 kube-scheduler
中的不同调度阶段。每个阶段都暴露于某个扩展点中。插件通过实现一个或多个扩展点来提供调度行为。
你可以通过运行 kube-scheduler --config <filename>
来设置调度模板,
使用 KubeSchedulerConfiguration (v1beta1) 结构体。
最简单的配置如下:
apiVersion : kubescheduler.config.k8s.io/v1beta1
kind : KubeSchedulerConfiguration
clientConnection :
kubeconfig : /etc/srv/kubernetes/kube-scheduler/kubeconfig
配置文件
通过调度配置文件,你可以配置 kube-scheduler 在不同阶段的调度行为。
每个阶段都在一个扩展点 中公开。
调度插件 通过实现一个或多个扩展点,来提供调度行为。
你可以配置同一 kube-scheduler
实例使用多个配置文件 。
扩展点
调度行为发生在一系列阶段中,这些阶段是通过以下扩展点公开的:
QueueSort
:这些插件对调度队列中的悬决的 Pod 排序。
一次只能启用一个队列排序插件。
PreFilter
:这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。
它们可以将 Pod 标记为不可调度。
Filter
:这些插件相当于调度策略中的断言(Predicates),用于过滤不能运行 Pod 的节点。
过滤器的调用顺序是可配置的。
如果没有一个节点通过所有过滤器的筛选,Pod 将会被标记为不可调度。
PreScore
:这是一个信息扩展点,可用于预打分工作。
Score
:这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。
Reserve
:这是一个信息扩展点,当资源已经预留给 Pod 时,会通知插件。
这些插件还实现了 Unreserve
接口,在 Reserve
期间或之后出现故障时调用。
Permit
:这些插件可以阻止或延迟 Pod 绑定。
PreBind
:这些插件在 Pod 绑定节点之前执行。
Bind
:这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的,只要有一个插件完成了绑定,其余插件都会跳过。绑定插件至少需要一个。
PostBind
:这是一个信息扩展点,在 Pod 绑定了节点之后调用。
对每个扩展点,你可以禁用默认插件 或者是启用自己的插件,例如:
apiVersion : kubescheduler.config.k8s.io/v1beta1
kind : KubeSchedulerConfiguration
profiles :
- plugins :
score :
disabled :
- name : NodeResourcesLeastAllocated
enabled :
- name : MyCustomPluginA
weight : 2
- name : MyCustomPluginB
weight : 1
你可以在 disabled
数组中使用 *
禁用该扩展点的所有默认插件。
如果需要,这个字段也可以用来对插件重新顺序。
调度插件
UnReserve
:这是一个信息扩展点,如果一个 Pod 在预留后被拒绝,并且被 Permit
插件搁置,它就会被调用。
调度插件
下面默认启用的插件实现了一个或多个扩展点:
DefaultBinder
:提供默认的绑定机制。
实现的扩展点:Bind
。
你也可以通过组件配置 API 启用以下插件(默认不启用):
多配置文件
你可以配置 kube-scheduler
运行多个配置文件。
每个配置文件都有一个关联的调度器名称,并且可以在其扩展点中配置一组不同的插件。
使用下面的配置样例,调度器将运行两个配置文件:一个使用默认插件,另一个禁用所有打分插件。
apiVersion : kubescheduler.config.k8s.io/v1beta1
kind : KubeSchedulerConfiguration
profiles :
- schedulerName : default-scheduler
- schedulerName : no -scoring-scheduler
plugins :
preScore :
disabled :
- name : '*'
score :
disabled :
- name : '*'
对于那些希望根据特定配置文件来进行调度的 Pod,可以在 .spec.schedulerName
字段指定相应的调度器名称。
默认情况下,将创建一个调度器名为 default-scheduler
的配置文件。
这个配置文件包括上面描述的所有默认插件。
声明多个配置文件时,每个配置文件中调度器名称必须唯一。
如果 Pod 未指定调度器名称,kube-apiserver 将会把调度器名设置为 default-scheduler
。
因此,应该存在一个调度器名为 default-scheduler
的配置文件来调度这些 Pod。
说明:
Pod 的调度事件把 .spec.schedulerName
字段值作为 ReportingController。
领导者选举事件使用列表中第一个配置文件的调度器名称。
说明:
所有配置文件必须在 QueueSort 扩展点使用相同的插件,并具有相同的配置参数(如果适用)。
这是因为调度器只有一个保存 pending 状态 Pod 的队列。
接下来
13.2 - 调度策略
在 Kubernetes v1.23 版本之前,可以使用调度策略来指定 predicates 和 priorities 进程。
例如,可以通过运行 kube-scheduler --policy-config-file <filename>
或者
kube-scheduler --policy-configmap <ConfigMap>
设置调度策略。
但是从 Kubernetes v1.23 版本开始,不再支持这种调度策略。
同样地也不支持相关的 policy-config-file
、 policy-configmap
、 policy-configmap-namespace
以及 use-legacy-policy-config
标志。
你可以通过使用 调度配置 来实现类似的行为。
接下来
14 - 其他工具
Kubernetes 包含多个内置工具来帮助你使用 Kubernetes 系统。
Minikube
minikube
是一种在你的工作站上本地运行单节点 Kubernetes 集群的工具,用于开发和测试。
仪表盘
Dashboard
,
基于 Web 的 Kubernetes 用户界面,
允许你将容器化的应用程序部署到 Kubernetes 集群,
对它们进行故障排查,并管理集群及其资源本身。
Helm
Kubernetes Helm
是一个用于管理预配置 Kubernetes 资源包的工具,也就是 Kubernetes 图表。
使用 Helm 来:
查找和使用打包为 Kubernetes 图表的流行软件
将你自己的应用程序共享为 Kubernetes 图表
为你的 Kubernetes 应用程序创建可重现的构建
智能管理你的 Kubernetes 清单文件
管理 Helm 包的发布
Kompose
Kompose
是一个帮助 Docker Compose 用户迁移到 Kubernetes 的工具。
使用 Kompose:
将 Docker Compose 文件翻译成 Kubernetes 对象
从本地 Docker 开发转到通过 Kubernetes 管理你的应用程序
转换 Docker Compose v1 或 v2 版本的 yaml
文件或分布式应用程序包
14.1 - 从 Docker 命令行映射到 crictl
说明:
本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循
CNCF 网站指南 ,按字母顺序列出项目。要将项目添加到此列表中,请在提交更改之前阅读
内容指南 。
说明:
此页面已被废弃,将在 Kubernetes 1.27 版本删除。
crictl
是兼容 CRI 的容器运行时的一种命令行接口。
你可以使用它来在 Kubernetes 节点上检视和调试容器运行时和应用。
crictl
及其源代码都托管在
cri-tools 仓库中。
本页面提供一份参考资料,用来将 docker
命令行工具的常用命令映射到
crictl
的等价命令。
从 docker 命令行映射到 crictl
映射表格中列举的确切版本是 docker
命令行的 v1.40 版本和 crictl
的 v1.19.0 版本。
这一列表不是完备的。例如,其中并未包含实验性质的 docker
命令。
说明:
crictl
的输出格式类似于 docker
命令行,只是对于某些命令而言会有部分列缺失。
如果你的命令输出会被程序解析,请确保你认真查看了对应的命令输出。
docker 命令行与 crictl 的映射 - 获得调试信息
docker CLI
crictl
描述
不支持的功能
attach
attach
挂接到某运行中的容器
--detach-keys
, --sig-proxy
exec
exec
在运行中的容器内执行命令
--privileged
, --user
, --detach-keys
images
images
列举镜像
info
info
显示系统范围的信息
inspect
inspect
, inspecti
返回容器、镜像或任务的底层信息
logs
logs
取回容器的日志数据
--details
ps
ps
列举容器
stats
stats
显示容器资源用量统计的动态数据流
列:NET/BLOCK I/O、PIDs
version
version
显示运行时(Docker、ContainerD 或其他)的版本信息
docker 命令行与 crictl 的映射 - 执行变更
docker CLI
crictl
描述
不支持的功能
create
create
创建一个新容器
kill
stop
(超时值为 0)
杀死一个或多个运行中的容器
--signal
pull
pull
从某镜像库拉取镜像或仓库
--all-tags
, --disable-content-trust
rm
rm
移除一个或者多个容器
rmi
rmi
移除一个或者多个镜像
run
run
在一个新的容器中执行命令
start
start
启动一个或多个已停止的容器
--detach-keys
stop
stop
停止一个或多个运行中的容器
update
update
更新一个或多个容器的配置
--restart
、--blkio-weight
以 CRI 所不支持的资源约束
仅被 crictl 支持的命令
docker 命令行与 crictl 的映射 - 仅被 crictl 支持的命令
crictl
描述
imagefsinfo
返回镜像文件系统信息
inspectp
显示一个或多个 Pod 的状态
port-forward
将本地端口转发到 Pod
pods
列举 Pod
runp
运行一个新的 Pod
rmp
删除一个或多个 Pod
stopp
停止一个或多个运行中的 Pod