生产级别的容器编排系统 on Kubernetes

APIService

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: apiregistration.k8s.io/v1

import "k8s.io/kube-aggregator/pkg/apis/apiregistration/v1"

APIService

APIService 是用来表示一个特定的 GroupVersion 的服务器。名称必须为 "version.group"。

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata (ObjectMeta)

标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (APIServiceSpec)

spec 包含用于定位和与服务器通信的信息

Babylon Case Study

Mon, 01 Jan 0001 00:00:00 +0000

Challenge

A large number of Babylon's products leverage machine learning and artificial intelligence, and in 2019, there wasn't enough computing power in-house to run a particular experiment. The company was also growing (from 100 to 1,600 in three years) and planning expansion into other countries.

Solution

Babylon had migrated its user-facing applications to a Kubernetes platform in 2018, so the infrastructure team turned to Kubeflow, a toolkit for machine learning on Kubernetes. "We tried to create a Kubernetes core server, we deployed Kubeflow, and we orchestrated the whole experiment, which ended up being a really good success," says AI Infrastructure Lead Jérémie Vallée. The team began building a self-service AI training platform on top of Kubernetes.

ConfigMap

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

ConfigMap

ConfigMap 包含供 Pod 使用的配置数据。

apiVersion: v1
kind: ConfigMap

metadata (ObjectMeta)

标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

binaryData (map[string][]byte)

CustomResourceDefinition

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: apiextensions.k8s.io/v1

import "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1"

CustomResourceDefinition

CustomResourceDefinition 表示应在 API 服务器上公开的资源。其名称必须采用 <.spec.name>.<.spec.group> 格式。

apiVersion：apiextensions.k8s.io/v1
kind：CustomResourceDefinition
metadata (ObjectMeta)

标准的对象元数据，更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

DeleteOptions

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/apimachinery/pkg/apis/meta/v1"

删除 API 对象时可以提供 DeleteOptions。

apiVersion (string)

FlowSchema

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: flowcontrol.apiserver.k8s.io/v1

import "k8s.io/api/flowcontrol/v1"

FlowSchema

FlowSchema 定义一组流的模式。请注意，一个流由属性类似的一组入站 API 请求组成，用一对字符串进行标识：FlowSchema 的名称和一个 “流区分项”。

kubectl 介绍

Mon, 01 Jan 0001 00:00:00 +0000

kubectl 是 Kubernetes CLI 版本的瑞士军刀，可以胜任多种多样的任务。

本文主要介绍如何使用 kubectl 在 Kubernetes 中声明式管理应用，本文还涵盖了一些其他的 kubectl 功能。

命令分类

大多数 kubectl 命令通常可以分为以下几类：

LocalSubjectAccessReview

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: authorization.k8s.io/v1

import "k8s.io/api/authorization/v1"

LocalSubjectAccessReview

LocalSubjectAccessReview 检查用户或组是否可以在给定的命名空间内执行某操作。划分命名空间范围的资源简化了命名空间范围的策略设置，例如权限检查。

Pod

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

Pod

Pod 是可以在主机上运行的容器的集合。此资源由客户端创建并调度到主机上。

apiVersion: v1
kind: Pod

metadata (ObjectMeta)

Service

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1”

Service

Service 是软件服务（例如 mysql）的命名抽象，包含代理要侦听的本地端口（例如 3306）和一个选择算符，选择算符用来确定哪些 Pod 将响应通过代理发送的请求。

ServiceAccount

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

ServiceAccount

ServiceAccount 将以下内容绑定在一起：

Binding

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

Binding

Binding 将一个对象与另一个对象绑定在一起；例如，调度程序将一个 Pod 绑定到一个节点。

apiVersion: v1
kind: Binding
metadata (ObjectMeta)

Booz Allen Case Study

Mon, 01 Jan 0001 00:00:00 +0000

Challenge

In 2017, Booz Allen Hamilton's Strategic Innovation Group worked with the federal government to relaunch the decade-old recreation.gov website, which provides information and real-time booking for more than 100,000 campsites and facilities on federal lands across the country. The infrastructure needed to be agile, reliable, and scalable—as well as repeatable for the other federal agencies that are among Booz Allen Hamilton's customers.

Solution

"The only way that we thought we could be successful with this problem across all the different agencies is to create a microservice architecture and containers, so that we could be very dynamic and very agile to any given agency for whatever requirements that they may have," says Booz Allen Hamilton Senior Lead Technologist Martin Folkoff. To meet those requirements, Folkoff's team looked to Kubernetes for orchestration.

Bose Case Study

Mon, 01 Jan 0001 00:00:00 +0000

挑战

作为一家以高品质音频设备闻名的公司，[Bose](https://www.bose.com/en_us/index.html) 已经提供了超过五年的联网产品，随着这一需求的增长，基础设施不得不改变以支持它。 “我们需要为开发者提供一种机制，能够快速原型化并部署服务一直到生产环境”，首席云工程师 Josh West 说道。 2016年，公司决定开始从头构建一个平台。其主要目标是：“要领先于各个产品组一到两步，这样我们就永远不会匆忙追赶他们的规模”，云架构经理 Dylan O'Mahony 说道。

ComponentStatus

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

ComponentStatus

ComponentStatus（和 ComponentStatusList）保存集群检验信息。已废弃：该 API 在 v1.19 及更高版本中废弃。

apiVersion: v1
kind: ComponentStatus
metadata (ObjectMeta)

标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

DeviceClass

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: resource.k8s.io/v1

import "k8s.io/api/resource/v1"

DeviceClass

DeviceClass 是由供应商或管理员提供的资源，包含设备配置和选择算符。它可以在申领的设备请求中被引用，以应用预设值。作用域为集群范围。

Endpoints

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

Endpoints

Endpoints 是实现实际 Service 的端点的集合。举例：

Name: "mysvc",
Subsets: [
 {
 Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2"}],
 Ports: [{"name": "a", "port": 8675}, {"name": "b", "port": 309}]
 },
 {
 Addresses: [{"ip": "10.10.3.3"}],
 Ports: [{"name": "a", "port": 93}, {"name": "b", "port": 76}]
 },
]

Endpoints 是遗留 API，不包含所有 Service 特性的信息。使用 discoveryv1.EndpointSlice 获取关于 Service 端点的完整信息。

LabelSelector

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/apimachinery/pkg/apis/meta/v1"

标签选择算符是对一组资源的标签查询。 matchLabels 和 matchExpressions 的结果按逻辑与的关系组合。一个 empty 标签选择算符匹配所有对象。一个 null 标签选择算符不匹配任何对象。

LimitRange

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

LimitRange

LimitRange 设置名字空间中每个资源类别的资源用量限制。

apiVersion: v1
kind: LimitRange

metadata (ObjectMeta)

Secret

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

Secret

Secret 包含某些类别的秘密数据。 data 字段值的总字节必须小于 MaxSecretSize 字节。

apiVersion: v1
kind: Secret

metadata (ObjectMeta)

SelfSubjectAccessReview

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: authorization.k8s.io/v1

import "k8s.io/api/authorization/v1"

SelfSubjectAccessReview

SelfSubjectAccessReview 检查当前用户是否可以执行某操作。不填写 spec.namespace 表示“在所有命名空间中”。 Self 是一个特殊情况，因为用户应始终能够检查自己是否可以执行某操作。

TokenRequest

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: authentication.k8s.io/v1

import "k8s.io/api/authentication/v1"

TokenRequest

TokenRequest 为给定的服务账号请求一个令牌。

apiVersion: authentication.k8s.io/v1
kind: TokenRequest

metadata (ObjectMeta)

Booking.com Case Study

Mon, 01 Jan 0001 00:00:00 +0000

Challenge

In 2016, Booking.com migrated to an OpenShift platform, which gave product developers faster access to infrastructure. But because Kubernetes was abstracted away from the developers, the infrastructure team became a "knowledge bottleneck" when challenges arose. Trying to scale that support wasn't sustainable.

Solution

After a year operating OpenShift, the platform team decided to build its own vanilla Kubernetes platform—and ask developers to learn some Kubernetes in order to use it. "This is not a magical platform," says Ben Tyler, Principal Developer, B Platform Track. "We're not claiming that you can just use it with your eyes closed. Developers need to do some learning, and we're going to do everything we can to make sure they have access to that knowledge."

CSIDriver

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

CSIDriver

CSIDriver 抓取集群上部署的容器存储接口（CSI）卷驱动有关的信息。 Kubernetes 挂接/解除挂接控制器使用此对象来决定是否需要挂接。 kubelet 使用此对象决定挂载时是否需要传递 Pod 信息。 CSIDriver 对象未划分命名空间。

EndpointSlice

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: discovery.k8s.io/v1

import "k8s.io/api/discovery/v1"

EndpointSlice

EndpointSlice 表示一组服务端点。大多数 EndpointSlice 由 EndpointSlice 控制器创建，用于表示被 Service 对象选中的 Pod。对于一个给定的服务，可能存在多个 EndpointSlice 对象，这些对象必须被组合在一起以产生完整的端点集合；你可以通过在服务的命名空间中列出 kubernetes.io/service-name 标签包含 Service 名称的 EndpointSlices 来找到给定 Service 的所有 slices。

Event

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: events.k8s.io/v1

import "k8s.io/api/events/v1"

Event

Event 是集群中某个事件的报告。它一般表示系统的某些状态变化。 Event 的保留时间有限，触发器和消息可能会随着时间的推移而演变。事件消费者不应假定给定原因的事件的时间所反映的是一致的下层触发因素，或具有该原因的事件的持续存在。 Events 应被视为通知性质的、尽最大努力而提供的补充数据。

ListMeta

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/apimachinery/pkg/apis/meta/v1"

ListMeta 描述了合成资源必须具有的元数据，包括列表和各种状态对象。一个资源仅能有 {ObjectMeta, ListMeta} 中的一个。

continue (string)

MutatingWebhookConfiguration

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: admissionregistration.k8s.io/v1

import "k8s.io/api/admissionregistration/v1"

MutatingWebhookConfiguration

MutatingWebhookConfiguration 描述准入 Webhook 的配置，该 Webhook 可接受或拒绝对象请求，并且可能变更对象。

apiVersion：admissionregistration.k8s.io/v1
kind：MutatingWebhookConfiguration

metadata (ObjectMeta)

PodTemplate

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

PodTemplate

PodTemplate 描述一种模板，用来为预定义的 Pod 生成副本。

apiVersion: v1
kind: PodTemplate
metadata (ObjectMeta)

标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
template (PodTemplateSpec)

template 定义将基于此 Pod 模板所创建的 Pod。 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

ResourceQuota

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

ResourceQuota

ResourceQuota 设置每个命名空间强制执行的聚合配额限制。

apiVersion: v1
kind: ResourceQuota
metadata (ObjectMeta)

标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (ResourceQuotaSpec)

spec 定义所需的配额。 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

SelfSubjectRulesReview

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: authorization.k8s.io/v1

import "k8s.io/api/authorization/v1"

SelfSubjectRulesReview

SelfSubjectRulesReview 枚举当前用户可以在某命名空间内执行的操作集合。返回的操作列表可能不完整，具体取决于服务器的鉴权模式以及评估过程中遇到的任何错误。 SelfSubjectRulesReview 应由 UI 用于显示/隐藏操作，或让最终用户尽快理解自己的权限。 SelfSubjectRulesReview 不得被外部系统使用以驱动鉴权决策，因为这会引起混淆代理人（Confused deputy）、缓存有效期/吊销（Cache lifetime/revocation）和正确性问题。 SubjectAccessReview 和 LocalAccessReview 是遵从 API 服务器所做鉴权决策的正确方式。

TokenReview

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: authentication.k8s.io/v1

import "k8s.io/api/authentication/v1"

TokenReview

TokenReview 尝试通过验证令牌来确认已知用户。注意：TokenReview 请求可能会被 kube-apiserver 中的 Webhook 令牌验证器插件缓存。

AppDirect Case Study

Mon, 01 Jan 0001 00:00:00 +0000

CASE STUDY:

AppDirect: How AppDirect Supported the 10x Growth of Its Engineering Staff with Kubernetes

Company AppDirect Location San Francisco, California Industry Software

Challenge

AppDirect provides an end-to-end commerce platform for cloud-based products and services. When Director of Software Development Pierre-Alexandre Lacerte began working there in 2014, the company had a monolith application deployed on a "tomcat infrastructure, and the whole release process was complex for what it should be," he says. "There were a lot of manual steps involved, with one engineer building a feature, then another team picking up the change. So you had bottlenecks in the pipeline to ship a feature to production." At the same time, the engineering team was growing, and the company realized it needed a better infrastructure to both support that growth and increase velocity.

Solution

"My idea was: Let’s create an environment where teams can deploy their services faster, and they will say, ‘Okay, I don’t want to build in the monolith anymore. I want to build a service,’" says Lacerte. They considered and prototyped several different technologies before deciding to adopt Kubernetes in early 2016. Lacerte’s team has also integrated Prometheus monitoring into the platform; tracing is next. Today, AppDirect has more than 50 microservices in production and 15 Kubernetes clusters deployed on AWS and on premise around the world.

Impact

The Kubernetes platform has helped support the engineering team’s 10x growth over the past few years. Coupled with the fact that they were continually adding new features, Lacerte says, "I think our velocity would have slowed down a lot if we didn’t have this new infrastructure." Moving to Kubernetes and services has meant that deployments have become much faster due to less dependency on custom-made, brittle shell scripts with SCP commands. Time to deploy a new version has shrunk from 4 hours to a few minutes. Additionally, the company invested a lot of effort to make things self-service for developers. "Onboarding a new service doesn’t require Jira tickets or meeting with three different teams," says Lacerte. Today, the company sees 1,600 deployments per week, compared to 1-30 before. The company also achieved cost savings by moving its marketplace and billing monoliths to Kubernetes from legacy EC2 hosts as well as by leveraging autoscaling, as traffic is higher during business hours.

"It was an immense engineering culture shift, but the benefits are undeniable in terms of scale and speed."

- Alexandre Gervais, Staff Software Developer, AppDirect

With its end-to-end commerce platform for cloud-based products and services, AppDirect has been helping organizations such as Comcast and GoDaddy simplify the digital supply chain since 2009.

When Director of Software Development Pierre-Alexandre Lacerte started working there in 2014, the company had a monolith application deployed on a "tomcat infrastructure, and the whole release process was complex for what it should be," he says. "There were a lot of manual steps involved, with one engineer building a feature then creating a pull request, and a QA or another engineer validating the feature. Then it gets merged and someone else will take care of the deployment. So we had bottlenecks in the pipeline to ship a feature to production."

At the same time, the engineering team of 40 was growing, and the company wanted to add an increasing number of features to its products. As a member of the platform team, Lacerte began hearing from multiple teams that wanted to deploy applications using different frameworks and languages, from Node.js to Spring Boot Java. He soon realized that in order to both support growth and increase velocity, the company needed a better infrastructure, and a system in which teams are autonomous, can do their own deploys, and be responsible for their services in production.

"We made the right decisions at the right time. Kubernetes and the cloud native technologies are now seen as the de facto ecosystem. We know where to focus our efforts in order to tackle the new wave of challenges we face as we scale out. The community is so active and vibrant, which is a great complement to our awesome internal team."

- Alexandre Gervais, Staff Software Developer, AppDirect

From the beginning, Lacerte says, "My idea was: Let’s create an environment where teams can deploy their services faster, and they will say, ‘Okay, I don’t want to build in the monolith anymore. I want to build a service.’" (Lacerte left the company in 2019.)

Working with the operations team, Lacerte’s group got more control and access to the company’s AWS infrastructure, and started prototyping several orchestration technologies. "Back then, Kubernetes was a little underground, unknown," he says. "But we looked at the community, the number of pull requests, the velocity on GitHub, and we saw it was getting traction. And we found that it was much easier for us to manage than the other technologies." They spun up the first few services on Kubernetes using Chef and Terraform provisioning, and as more services were added, more automation was, too. "We have clusters around the world—in Korea, in Australia, in Germany, and in the U.S.," says Lacerte. "Automation is critical for us." They’re now largely using Kops, and are looking at managed Kubernetes offerings from several cloud providers.

Today, though the monolith still exists, there are fewer and fewer commits and features. All teams are deploying on the new infrastructure, and services are the norm. AppDirect now has more than 50 microservices in production and 15 Kubernetes clusters deployed on AWS and on premise around the world.

Lacerte’s strategy ultimately worked because of the very real impact the Kubernetes platform has had to deployment time. Due to less dependency on custom-made, brittle shell scripts with SCP commands, time to deploy a new version has shrunk from 4 hours to a few minutes. Additionally, the company invested a lot of effort to make things self-service for developers. "Onboarding a new service doesn’t require Jira tickets or meeting with three different teams," says Lacerte. Today, the company sees 1,600 deployments per week, compared to 1-30 before.

"I think our velocity would have slowed down a lot if we didn’t have this new infrastructure."

- Pierre-Alexandre Lacerte, Director of Software Development, AppDirect

Additionally, the Kubernetes platform has helped support the engineering team’s 10x growth over the past few years. "Ownership, a core value of AppDirect, reflects in our ability to ship services independently of our monolith code base," says Staff Software Developer Alexandre Gervais, who worked with Lacerte on the initiative. "Small teams now own critical parts of our business domain model, and they operate in their decoupled domain of expertise, with limited knowledge of the entire codebase. This reduces and isolates some of the complexity." Coupled with the fact that they were continually adding new features, Lacerte says, "I think our velocity would have slowed down a lot if we didn’t have this new infrastructure." The company also achieved cost savings by moving its marketplace and billing monoliths to Kubernetes from legacy EC2 hosts as well as by leveraging autoscaling, as traffic is higher during business hours.

AppDirect’s cloud native stack also includes gRPC and Fluentd, and the team is currently working on setting up OpenCensus. The platform already has Prometheus integrated, so "when teams deploy their service, they have their notifications, alerts and configurations," says Lacerte. "For example, in the test environment, I want to get a message on Slack, and in production, I want a Slack message and I also want to get paged. We have integration with pager duty. Teams have more ownership on their services."

"We moved from a culture limited to ‘pushing code in a branch’ to exciting new responsibilities outside of the code base: deployment of features and configurations; monitoring of application and business metrics; and on-call support in case of outages. It was an immense engineering culture shift, but the benefits are undeniable in terms of scale and speed."

- Pierre-Alexandre Lacerte, Director of Software Development, AppDirect

That of course also means more responsibility. "We asked engineers to expand their horizons," says Gervais. "We moved from a culture limited to ‘pushing code in a branch’ to exciting new responsibilities outside of the code base: deployment of features and configurations; monitoring of application and business metrics; and on-call support in case of outages. It was an immense engineering culture shift, but the benefits are undeniable in terms of scale and speed."

As the engineering ranks continue to grow, the platform team has a new challenge, of making sure that the Kubernetes platform is accessible and easily utilized by everyone. "How can we make sure that when we add more people to our team that they are efficient, productive, and know how to ramp up on the platform?" Lacerte says. So we have the evangelists, the documentation, some project examples. We do demos, we have AMA sessions. We’re trying different strategies to get everyone’s attention."

Three and a half years into their Kubernetes journey, Gervais feels AppDirect "made the right decisions at the right time," he says. "Kubernetes and the cloud native technologies are now seen as the de facto ecosystem. We know where to focus our efforts in order to tackle the new wave of challenges we face as we scale out. The community is so active and vibrant, which is a great complement to our awesome internal team. Going forward, our focus will really be geared towards benefiting from the ecosystem by providing added business value in our day-to-day operations."

CertificateSigningRequest

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: certificates.k8s.io/v1

import "k8s.io/api/certificates/v1"

证书签名请求 CertificateSigningRequest

CertificateSigningRequest 对象提供了一种通过提交证书签名请求并异步批准和颁发 x509 证书的机制。

CSINode

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

CSINode

CSINode 包含节点上安装的所有 CSI 驱动有关的信息。CSI 驱动不需要直接创建 CSINode 对象。只要这些驱动使用 node-driver-registrar 边车容器，kubelet 就会自动为 CSI 驱动填充 CSINode 对象，作为 kubelet 插件注册操作的一部分。CSINode 的名称与节点名称相同。如果不存在此对象，则说明该节点上没有可用的 CSI 驱动或 Kubelet 版本太低无法创建该对象。 CSINode 包含指向相应节点对象的 OwnerReference。

Denso Case Study

Mon, 01 Jan 0001 00:00:00 +0000

Challenge

DENSO Corporation is one of the biggest automotive components suppliers in the world. With the advent of connected cars, the company launched a Digital Innovation Department to expand into software, working on vehicle edge and vehicle cloud products. But there were several technical challenges to creating an integrated vehicle edge/cloud platform: "the amount of computing resources, the occasional lack of mobile signal, and an enormous number of distributed vehicles," says R&D Product Manager Seiichi Koizumi.

Ingress

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: networking.k8s.io/v1

import "k8s.io/api/networking/v1"

Ingress

Ingress 是允许入站连接到达后端定义的端点的规则集合。 Ingress 可以配置为向服务提供外部可访问的 URL、负载均衡流量、终止 SSL、提供基于名称的虚拟主机等。

IPAddress

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: networking.k8s.io/v1

import "k8s.io/api/networking/v1"

IPAddress

IPAddress 表示单个 IP 族的单个 IP。此对象旨在供操作 IP 地址的 API 使用。此对象由 Service 核心 API 用于分配 IP 地址。 IP 地址可以用不同的格式表示，为了保证 IP 地址的唯一性，此对象的名称是格式规范的 IP 地址。 IPv4 地址由点分隔的四个十进制数字组成，前导零可省略；IPv6 地址按照 RFC 5952 的定义来表示。有效值：192.168.1.5、2001:db8::1 或 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1。无效值：10.01.2.3 或 2001:db8:0:0:0::1。

LocalObjectReference

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/api/core/v1"

LocalObjectReference 包含足够的信息，可以让你在同一命名空间（namespace）内找到引用的对象。

name (string)

NetworkPolicy

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: networking.k8s.io/v1

import "k8s.io/api/networking/v1"

NetworkPolicy

NetworkPolicy 描述针对一组 Pod 所允许的网络流量。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata (ObjectMeta)

标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (NetworkPolicySpec)

Ocado Case Study

Mon, 01 Jan 0001 00:00:00 +0000

Challenge

The world's largest online-only grocery retailer, Ocado developed the Ocado Smart Platform to manage its own operations, from websites to warehouses, and is now licensing the technology to other retailers such as Kroger. To set up the first warehouses for the platform, Ocado shifted from virtual machines and Puppet infrastructure to Docker containers, using CoreOS's fleet scheduler to provision all the services on its OpenStack-based private cloud on bare metal. As the Smart Platform grew and "fleet was going end-of-life," says Platform Engineer Mike Bryant, "we started looking for a more complete platform, with all of these disparate infrastructure services being brought together in one unified API."

ReplicaSet

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

ReplicaSet

ReplicaSet 确保在任何给定的时刻都在运行指定数量的 Pod 副本。

apiVersion: apps/v1
kind: ReplicaSet

metadata (ObjectMeta)

ReplicationController

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

ReplicationController

ReplicationController 表示一个副本控制器的配置。

apiVersion: v1
kind: ReplicationController

metadata (ObjectMeta)

SubjectAccessReview

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: authorization.k8s.io/v1

import "k8s.io/api/authorization/v1"

SubjectAccessReview

SubjectAccessReview 检查用户或组是否可以执行某操作。

apiVersion: authorization.k8s.io/v1
kind: SubjectAccessReview
metadata (ObjectMeta)

标准的列表元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

spec (SubjectAccessReviewSpec)，必需

ValidatingWebhookConfiguration

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: admissionregistration.k8s.io/v1

import "k8s.io/api/admissionregistration/v1"

ValidatingWebhookConfiguration

ValidatingWebhookConfiguration 描述准入 Webhook 的配置，此 Webhook 可在不更改对象的情况下接受或拒绝对象请求。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration

metadata (ObjectMeta)

ClusterRole

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

ClusterRole

ClusterRole 是一个集群级别的 PolicyRule 逻辑分组，可以被 RoleBinding 或 ClusterRoleBinding 作为一个单元引用。

ClusterTrustBundle v1beta1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: certificates.k8s.io/v1beta1

import "k8s.io/api/certificates/v1beta1"

ClusterTrustBundle

ClusterTrustBundle 是一个集群范围的容器，用于存放 X.509 信任锚（根证书）。

CSIStorageCapacity

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

CSIStorageCapacity

CSIStorageCapacity 存储一个 CSI GetCapacity 调用的结果。对于给定的 StorageClass，此结构描述了特定拓扑段中可用的容量。当考虑在哪里实例化新的 PersistentVolume 时可以使用此项。

IngressClass

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: networking.k8s.io/v1

import "k8s.io/api/networking/v1"

IngressClass

IngressClass 代表 Ingress 的类，被 Ingress 的规约引用。 ingressclass.kubernetes.io/is-default-class 注解可以用来标明一个 IngressClass 应该被视为默认的 Ingress 类。当某个 IngressClass 资源将此注解设置为 true 时，没有指定类的新 Ingress 资源将被分配到此默认类。

Lease

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: coordination.k8s.io/v1

import "k8s.io/api/coordination/v1"

Lease

Lease 定义了租约的概念。

apiVersion: coordination.k8s.io/v1
kind: Lease

metadata (ObjectMeta)

更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (LeaseSpec)

spec 包含 Lease 的规约。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

NodeSelectorRequirement

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/api/core/v1"

节点选择算符需求是一个选择算符，其中包含值集、主键以及一个将键和值集关联起来的操作符。

key (string)，必需

PodDisruptionBudget

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: policy/v1

import "k8s.io/api/policy/v1"

PodDisruptionBudget

PodDisruptionBudget 是一个对象，用于定义可能对一组 Pod 造成的最大干扰。

apiVersion: policy/v1
kind: PodDisruptionBudget

metadata (ObjectMeta)

词汇表

Mon, 01 Jan 0001 00:00:00 +0000

构建一个基本的 DaemonSet

Mon, 01 Jan 0001 00:00:00 +0000

本页演示如何构建一个基本的 DaemonSet，用其在 Kubernetes 集群中的每个节点上运行 Pod。这个简单的使用场景包含了从主机挂载一个文件，使用 Init 容器记录文件的内容，以及使用 pause 容器。

你好，Minikube

Mon, 01 Jan 0001 00:00:00 +0000

本教程向你展示如何使用 Minikube 在 Kubernetes 上运行一个应用示例。教程提供了容器镜像，使用 NGINX 来对所有请求做出回应。

教程目标

将一个示例应用部署到 Minikube。
运行应用程序。
查看应用日志。

准备开始

本教程假设你已经安装了 minikube。有关安装说明，请参阅 minikube start 的步骤 1。

ClusterRoleBinding

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

ClusterRoleBinding

ClusterRoleBinding 引用 ClusterRole，但不包含它。它可以引用全局命名空间中的 ClusterRole，并通过 Subject 添加主体信息。

apiVersion: rbac.authorization.k8s.io/v1

Deployment

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

Deployment

Deployment 使得 Pod 和 ReplicaSet 能够进行声明式更新。

apiVersion: apps/v1
kind: Deployment

metadata (ObjectMeta)

LeaseCandidate v1beta1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: coordination.k8s.io/v1beta1

import "k8s.io/api/coordination/v1beta1"

LeaseCandidate

LeaseCandidate 定义一个 Lease 对象的候选者。通过创建候选者，协同式领导者选举能够从候选者列表中选出最佳的领导者。

apiVersion: coordination.k8s.io/v1beta1
kind: LeaseCandidate

metadata (ObjectMeta)

ObjectFieldSelector

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/api/core/v1"

ObjectFieldSelector 选择对象的 APIVersioned 字段。

fieldPath (string)，必需

PersistentVolumeClaim

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

PersistentVolumeClaim

PersistentVolumeClaim 是用户针对一个持久卷的请求和申领。

apiVersion: v1
kind: PersistentVolumeClaim

metadata (ObjectMeta)

PriorityLevelConfiguration v1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: flowcontrol.apiserver.k8s.io/v1

import "k8s.io/api/flowcontrol/v1"

PriorityLevelConfiguration

PriorityLevelConfiguration 表示一个优先级的配置。

apiVersion: flowcontrol.apiserver.k8s.io/v1
kind: PriorityLevelConfiguration

metadata (ObjectMeta)

SelfSubjectReview

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: authentication.k8s.io/v1

import "k8s.io/api/authentication/v1"

SelfSubjectReview

SelfSubjectReview 包含 kube-apiserver 所拥有的与发出此请求的用户有关的用户信息。使用伪装时，用户将收到被伪装用户的用户信息。如果使用伪装或请求头部进行身份验证，则所有额外的键都将被忽略大小写并以小写形式返回结果。

Namespace

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

Namespace

Namespace 为名字提供作用域。使用多个命名空间是可选的。

apiVersion: v1
kind: Namespace
metadata (ObjectMeta)

标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (NamespaceSpec)

spec 定义了 Namespace 的行为。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

ObjectMeta

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/apimachinery/pkg/apis/meta/v1"

ObjectMeta 是所有持久化资源必须具有的元数据，其中包括用户必须创建的所有对象。

name (string)

name 在命名空间内必须是唯一的。创建资源时需要，尽管某些资源可能允许客户端请求自动地生成适当的名称。名称主要用于创建幂等性和配置定义。无法更新。更多信息： https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names#names

PersistentVolume

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

PersistentVolume

PersistentVolume (PV) 是管理员制备的一个存储资源。它类似于一个节点。更多信息： https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes

apiVersion: v1
kind: PersistentVolume

metadata (ObjectMeta)

Role

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

Role

Role 是一个按命名空间划分的 PolicyRule 逻辑分组，可以被 RoleBinding 作为一个单元引用。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role

StatefulSet

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

StatefulSet

StatefulSet 表示一组具有一致身份的 Pod。身份定义为：

ValidatingAdmissionPolicy

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: admissionregistration.k8s.io/v1

import "k8s.io/api/admissionregistration/v1"

ValidatingAdmissionPolicy

ValidatingAdmissionPolicy 描述了一种准入验证策略的定义，这种策略用于接受或拒绝一个对象，而不对其进行修改。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata (ObjectMeta)

ControllerRevision

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

ControllerRevision

ControllerRevision 实现了状态数据的不可变快照。客户端负责序列化和反序列化对象，包含对象内部状态。成功创建 ControllerRevision 后，将无法对其进行更新。 API 服务器将无法成功验证所有尝试改变 data 字段的请求。但是，可以删除 ControllerRevisions。请注意，由于 DaemonSet 和 StatefulSet 控制器都使用它来进行更新和回滚，所以这个对象是 Beta 版。但是，它可能会在未来版本中更改名称和表示形式，客户不应依赖其稳定性。它主要供控制器内部使用。

Node

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

Node

Node 是 Kubernetes 中的工作节点。每个节点在缓存中（即在 etcd 中）都有一个唯一的标识符。

apiVersion: v1
kind: Node

metadata (ObjectMeta)

ObjectReference

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/api/core/v1"

ObjectReference 包含足够的信息，允许你检查或修改引用的对象。

apiVersion (string)

RoleBinding

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

RoleBinding

RoleBinding 引用一个角色，但不包含它。 RoleBinding 可以引用相同命名空间中的 Role 或全局命名空间中的 ClusterRole。 RoleBinding 通过 Subjects 和所在的命名空间信息添加主体信息。处于给定命名空间中的 RoleBinding 仅在该命名空间中有效。

StorageClass

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

StorageClass

StorageClass 为可以动态制备 PersistentVolume 的存储类描述参数。

ValidatingAdmissionPolicyBinding

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: admissionregistration.k8s.io/v1

DaemonSet

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

DaemonSet

DaemonSet 表示守护进程集的配置。

apiVersion: apps/v1
kind: DaemonSet

metadata (ObjectMeta)

标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

spec (DaemonSetSpec)

Patch

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/apimachinery/pkg/apis/meta/v1"

提供 Patch 是为了给 Kubernetes PATCH 请求正文提供一个具体的名称和类型。

RuntimeClass

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: node.k8s.io/v1

import "k8s.io/api/node/v1"

RuntimeClass

RuntimeClass 定义集群中支持的容器运行时类。 RuntimeClass 用于确定哪个容器运行时用于运行某 Pod 中的所有容器。 RuntimeClass 由用户或集群制备程序手动定义，并在 PodSpec 中引用。 kubelet 负责在运行 Pod 之前解析 RuntimeClassName 引用。有关更多详细信息，请参阅 https://kubernetes.io/zh-cn/docs/concepts/containers/runtime-class/

StorageVersionMigration v1alpha1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: storagemigration.k8s.io/v1alpha1

import "k8s.io/api/storagemigration/v1alpha1"

StorageVersionMigration

StorageVersionMigration 表示存储的数据向最新存储版本的一次迁移。

apiVersion: storagemigration.k8s.io/v1alpha1
kind: StorageVersionMigration

metadata (ObjectMeta)

Deployments

Mon, 01 Jan 0001 00:00:00 +0000

一个 Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力。

Job

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: batch/v1

import "k8s.io/api/batch/v1"

Job

Job 表示单个任务的配置。

apiVersion: batch/v1
kind: Job

metadata (ObjectMeta)

标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

spec (JobSpec)

kubectl 故障排查

Mon, 01 Jan 0001 00:00:00 +0000

本文讲述研判和诊断 kubectl 相关的问题。如果你在访问 kubectl 或连接到集群时遇到问题，本文概述了各种常见的情况和可能的解决方案，以帮助确定和解决可能的原因。

准备开始

你需要有一个 Kubernetes 集群。
你还需要安装好 kubectl，参见安装工具。

验证 kubectl 设置

确保你已在本机上正确安装和配置了 kubectl。检查 kubectl 版本以确保其是最新的，并与你的集群兼容。

kubectl 快速参考

Mon, 01 Jan 0001 00:00:00 +0000

本页列举常用的 kubectl 命令和参数。

说明：

这些指令适用于 Kubernetes v1.35。要检查版本，请使用 kubectl version 命令。

kubectl 自动补全

BASH

source <(kubectl completion bash) # 在 bash 中设置当前 shell 的自动补全，要先安装 bash-completion 包
echo "source <(kubectl completion bash)" >> ~/.bashrc # 在你的 bash shell 中永久地添加自动补全

你还可以在补全时为 kubectl 使用一个速记别名：

Kubelet Checkpoint API

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.30 [beta]（默认启用）

为容器生成检查点这个功能可以为一个正在运行的容器创建有状态的拷贝。一旦容器有一个有状态的拷贝，你就可以将其移动到其他计算机进行调试或类似用途。

Kubernetes 调度器

Mon, 01 Jan 0001 00:00:00 +0000

在 Kubernetes 中，调度是指将 Pod 放置到合适的节点上，以便对应节点上的 Kubelet 能够运行这些 Pod。

调度概览

调度器通过 Kubernetes 的监测（Watch）机制来发现集群中新创建且尚未被调度到节点上的 Pod。调度器会将所发现的每一个未调度的 Pod 调度到一个合适的节点上来运行。调度器会依据下文的调度原则来做出调度选择。

Kubernetes 文档支持的版本

Mon, 01 Jan 0001 00:00:00 +0000

本网站包含当前版本和之前四个版本的 Kubernetes 文档。

Kubernetes 问题追踪

Mon, 01 Jan 0001 00:00:00 +0000

要报告安全问题，请遵循 Kubernetes 安全问题公开流程。

使用 GitHub Issues 跟踪 Kubernetes 编码工作和公开问题。

与安全性相关的公告将发送到 kubernetes-security-announce@googlegroups.com 邮件列表。

Kubernetes 组件

Mon, 01 Jan 0001 00:00:00 +0000

本文档概述了一个正常运行的 Kubernetes 集群所需的各种组件。

Kubernetes 集群的组件

核心组件

Kubernetes 集群由控制平面和一个或多个工作节点组成。以下是主要组件的简要概述：

Linux 内核版本要求

Mon, 01 Jan 0001 00:00:00 +0000

说明： 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循CNCF 网站指南，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读内容指南。

许多特性依赖于特定的内核功能，并且有最低的内核版本要求。然而，单纯依赖内核版本号可能不足以满足某些操作系统发行版，因为像 RHEL、Ubuntu 和 SUSE 等发行版的维护者们通常会将选定的特性反向移植到较旧的内核版本（保留较旧的内核版本）。

Quantity

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/apimachinery/pkg/api/resource"

数量（Quantity）是数字的定点表示。除了 String() 和 AsInt64() 的访问接口之外，它以 JSON 和 YAML 形式提供方便的打包和解包方法。

序列化格式如下：

<quantity> ::= <signedNumber><suffix>

（注意 <suffix> 可能为空，例如 <decimalSI> 的 "" 情形。）

<digit> ::= 0 | 1 | ... | 9
<digits> ::= <digit> | <digit><digits>
<number> ::= <digits> | <digits>.<digits> | <digits>. | .<digits>
<sign> ::= "+" | "-"
<signedNumber> ::= <number> | <sign><number>
<suffix> ::= <binarySI> | <decimalExponent> | <decimalSI>
<binarySI> ::= Ki | Mi | Gi | Ti | Pi | Ei

（国际单位制度；查阅： http://physics.nist.gov/cuu/Units/binary.html）

<decimalSI> ::= m | "" | k | M | G | T | P | E

（注意，1024 = 1ki 但 1000 = 1k；我没有选择大写。）

<decimalExponent> ::= "e" <signedNumber> | "E" <signedNumber>

无论使用三种指数形式中哪一种，没有数量可以表示大于 2⁶³-1 的数，也不可能超过 3 个小数位。更大或更精确的数字将被截断或向上取整（例如：0.1m 将向上取整为 1m）。如果将来我们需要更大或更小的数量，可能会扩展。

参考文档快速入门

Mon, 01 Jan 0001 00:00:00 +0000

本页讨论如何使用 update-imported-docs.py 脚本来生成 Kubernetes 参考文档。此脚本将构建的配置过程自动化，并为某个发行版本生成参考文档。

准备开始

需求

你需要一台 Linux 或 macOS 机器。

Service 所用的协议

Mon, 01 Jan 0001 00:00:00 +0000

如果你配置 Service，你可以从 Kubernetes 支持的任何网络协议中选择一个协议。

Kubernetes 支持以下协议用于 Service：

SCTP
TCP （默认值）
UDP

当你定义 Service 时，你还可以指定其使用的应用协议。

ServiceCIDR

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: networking.k8s.io/v1

import "k8s.io/api/networking/v1"

ServiceCIDR

ServiceCIDR 使用 CIDR 格式定义 IP 地址的范围（例如 192.168.0.0/24 或 2001:db2::/64）。此范围用于向 Service 对象分配 ClusterIP。

StatefulSet 基础

Mon, 01 Jan 0001 00:00:00 +0000

本教程介绍了如何使用 StatefulSet 来管理应用。演示了如何创建、删除、扩容/缩容和更新 StatefulSet 的 Pod。

Volume

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/api/core/v1"

Volume

Volume 表示 Pod 中一个有名字的卷，可以由 Pod 中的任意容器进行访问。

name (string)，必需

安装 kubeadm

Mon, 01 Jan 0001 00:00:00 +0000

本页面显示如何安装 kubeadm 工具箱。有关在执行此安装过程后如何使用 kubeadm 创建集群的信息，请参见使用 kubeadm 创建集群。

此 installation guide 适用于 Kubernetes v1.35。如果你想使用其他 Kubernetes 版本，请参考以下页面：

部署和访问 Kubernetes 仪表板（Dashboard）

Mon, 01 Jan 0001 00:00:00 +0000

Dashboard 是基于网页的 Kubernetes 用户界面。你可以使用 Dashboard 将容器应用部署到 Kubernetes 集群中，也可以对容器应用排错，还能管理集群资源。你可以使用 Dashboard 获取运行在集群中的应用的概览信息，也可以创建或者修改 Kubernetes 资源（如 Deployment、Job、DaemonSet 等等）。例如，你可以对 Deployment 实现弹性伸缩、发起滚动升级、重启 Pod 或者使用向导创建新的应用。

查看 Pod 和节点

Mon, 01 Jan 0001 00:00:00 +0000

教程目标

了解 Kubernetes Pod。
了解 Kubernetes 节点。
对已部署的应用进行故障排查。

Kubernetes Pod

Pod 是一个或多个应用容器（例如 Docker）的组合，并且包含共享的存储（卷）、IP 地址和有关如何运行它们的信息。

大规模集群的注意事项

Mon, 01 Jan 0001 00:00:00 +0000

集群包含多个运行着 Kubernetes 代理程序、由控制平面管理的一组节点（物理机或虚拟机）。 Kubernetes v1.35 单个集群支持的最大节点数为 5,000。更具体地说，Kubernetes 设计为满足以下所有标准的配置：

调试 Pod

Mon, 01 Jan 0001 00:00:00 +0000

本指南帮助用户调试那些部署到 Kubernetes 上后没有正常运行的应用。本指南并非指导用户如何调试集群。如果想调试集群的话，请参阅这里。

诊断问题

故障排查的第一步是先给问题分类。问题是什么？是关于 Pod、Replication Controller 还是 Service？

定制资源

Mon, 01 Jan 0001 00:00:00 +0000

定制资源（Custom Resource） 是对 Kubernetes API 的扩展。本页讨论何时向 Kubernetes 集群添加定制资源，何时使用独立的服务。本页描述添加定制资源的两种方法以及怎样在二者之间做出抉择。

对 DaemonSet 执行滚动更新

Mon, 01 Jan 0001 00:00:00 +0000

本文介绍了如何对 DaemonSet 执行滚动更新。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

发起拉取请求（PR）

Mon, 01 Jan 0001 00:00:00 +0000

说明：

代码开发者们：如果你在为下一个 Kubernetes 发行版本中的某功能特性撰写文档，请参考为发行版本撰写功能特性文档。

要贡献新的内容页面或者改进已有内容页面，请发起拉取请求（PR）。请确保你满足了开始之前一节中所列举的所有要求。

服务（Service）

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 中 Service 是将运行在一个或一组 Pod 上的网络应用程序公开为网络服务的方法。

公开外部 IP 地址以访问集群中的应用

Mon, 01 Jan 0001 00:00:00 +0000

此页面显示如何创建公开外部 IP 地址的 Kubernetes 服务对象。

准备开始

安装 kubectl。
使用 Google Kubernetes Engine 或 Amazon Web Services 等云供应商创建 Kubernetes 集群。本教程创建了一个外部负载均衡器，需要云供应商。
配置 kubectl 与 Kubernetes API 服务器通信。有关说明，请参阅云供应商文档。

教程目标

运行 Hello World 应用的五个实例。
创建一个公开外部 IP 地址的 Service 对象。
使用 Service 对象访问正在运行的应用。

为在五个 Pod 中运行的应用创建服务

在集群中运行 Hello World 应用：

将节点上的容器运行时从 Docker Engine 改为 containerd

Mon, 01 Jan 0001 00:00:00 +0000

本任务给出将容器运行时从 Docker 改为 containerd 所需的步骤。此任务适用于运行 1.23 或更早版本 Kubernetes 的集群操作人员。同时，此任务也涉及从 dockershim 迁移到 containerd 的示例场景。有关其他备选的容器运行时，可查阅此页面进行拣选。

角色与责任

Mon, 01 Jan 0001 00:00:00 +0000

任何人都可以为 Kubernetes 作出贡献。随着你对 SIG Docs 的贡献增多，你可以申请社区内不同级别的成员资格。这些角色使得你可以在社区中承担更多的责任。每个角色都需要更多的时间和投入。具体包括：

节点

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行你的工作负载。节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。每个节点包含运行 Pod 所需的服务；这些节点由控制面负责管理。

节点关闭

Mon, 01 Jan 0001 00:00:00 +0000

在 Kubernetes 集群中，节点可以按计划的体面方式关闭，也可能因断电或其他某些外部原因被意外关闭。如果节点在关闭之前未被排空，则节点关闭可能会导致工作负载失败。节点可以体面关闭或非体面关闭。

镜像

Mon, 01 Jan 0001 00:00:00 +0000

容器镜像（Image）所承载的是封装了应用程序及其所有软件依赖的二进制数据。容器镜像是可执行的软件包，可以单独运行；该软件包对所处的运行时环境具有明确定义的运行时环境假定。

卷

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 卷为 Pod 中的容器提供了一种通过文件系统访问和共享数据的方式。存在不同类别的卷，你可以将其用于各种用途，例如：

文档内容指南

Mon, 01 Jan 0001 00:00:00 +0000

本页包含 Kubernetes 文档的一些指南。

如果你不清楚哪些事情是可以做的，请加入到 Kubernetes Slack 的 #sig-docs 频道提问！你可以在 https://slack.k8s.io 注册到 Kubernetes Slack。

配置聚合层

Mon, 01 Jan 0001 00:00:00 +0000

配置聚合层可以允许 Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心 Kubernetes API 的一部分。

准备开始

评审 PR

Mon, 01 Jan 0001 00:00:00 +0000

任何人均可评审文档的拉取请求。访问 Kubernetes 网站仓库的 pull requests 部分，可以查看所有待处理的拉取请求（PR）。

审计注解

Mon, 01 Jan 0001 00:00:00 +0000

本页面作为 kubernetes.io 名字空间的审计注解的参考。这些注解适用于 API 组 audit.k8s.io 中的 Event 对象。

说明：

Kubernetes API 中不使用以下注解。当你在集群中启用审计时，审计事件数据将使用 API 组 audit.k8s.io 中的 Event 写入。此注解适用于审计事件。审计事件不同于 Event API （API 组 events.k8s.io）中的对象。

使用 Antrea 提供 NetworkPolicy

Mon, 01 Jan 0001 00:00:00 +0000

本页展示了如何在 kubernetes 中安装和使用 Antrea CNI 插件。要了解 Antrea 项目的背景，请阅读 Antrea 介绍。

准备开始

你需要拥有一个 kuernetes 集群。遵循 kubeadm 入门指南自行创建一个。

使用 CronJob 运行自动化任务

Mon, 01 Jan 0001 00:00:00 +0000

本页演示如何使用 Kubernetes CronJob 对象运行自动化任务。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

使用 Deployment 运行一个无状态应用

Mon, 01 Jan 0001 00:00:00 +0000

本文介绍如何通过 Kubernetes Deployment 对象去运行一个应用。

教程目标

创建一个 nginx Deployment。
使用 kubectl 列举该 Deployment 的相关信息。
更新该 Deployment。

准备开始

使用 kubectl 创建 Deployment

Mon, 01 Jan 0001 00:00:00 +0000

教程目标

学习应用的部署。
使用 kubectl 在 Kubernetes 上部署第一个应用。

Kubernetes Deployment

Deployment 负责创建和更新应用的实例

说明：

本教程使用了一个需要 AMD64 架构的容器。如果你在使用 Minikube 的计算机上使用了不同的 CPU 架构，可以尝试使用能够模拟 AMD64 的 Minikube 驱动程序。例如，Docker Desktop 驱动程序可以实现这一点。

使用 kubectl 管理 Secret

Mon, 01 Jan 0001 00:00:00 +0000

本页向你展示如何使用 kubectl 命令行工具来创建、编辑、管理和删除。 Kubernetes Secrets

准备开始

使用 Minikube 创建集群

Mon, 01 Jan 0001 00:00:00 +0000

教程目标

了解 Kubernetes 集群。
了解 Minikube。
在你的电脑上启动一个 Kubernetes 集群。

Kubernetes 集群

Kubernetes 是一个生产级别的开源平台，可编排在计算机集群内和跨计算机集群的应用容器的部署（调度）和执行。

使用 Service 公开你的应用

Mon, 01 Jan 0001 00:00:00 +0000

教程目标

了解 Kubernetes 中的 Service
了解标签（Label）和选择算符（Selector）如何与 Service 关联
用 Service 向 Kubernetes 集群外公开应用

Kubernetes Service 概述

Kubernetes Pod 是有生命期的。 Pod 拥有生命周期。当一个工作节点停止工作后，在节点上运行的 Pod 也会消亡。 ReplicaSet 会自动地通过创建新的 Pod 驱动集群回到期望状态，以保证应用正常运行。换一个例子，考虑一个具有 3 个副本的用作图像处理的后端程序。这些副本是彼此可替换的。前端系统不应该关心后端副本，即使某个 Pod 丢失或被重新创建。此外，Kubernetes 集群中的每个 Pod 都有一个唯一的 IP 地址，即使是在同一个 Node 上的 Pod 也是如此，因此需要一种方法来自动协调 Pod 集合中的变化，以便应用保持运行。

使用配置文件对 Kubernetes 对象进行声明式管理

Mon, 01 Jan 0001 00:00:00 +0000

你可以通过在一个目录中存储多个对象配置文件、并使用 kubectl apply 来递归地创建和更新对象来创建、更新和删除 Kubernetes 对象。这种方法会保留对现有对象已作出的修改，而不会将这些更改写回到对象配置文件中。 kubectl diff 也会给你呈现 apply 将作出的变更的预览。

特性门控

Mon, 01 Jan 0001 00:00:00 +0000

本页详述了管理员可以在不同的 Kubernetes 组件上指定的各种特性门控。

关于特性各个阶段的说明，请参见特性阶段。

概述

特性门控是描述 Kubernetes 特性的一组键值对。你可以在 Kubernetes 的各个组件中使用 --feature-gates 标志来启用或禁用这些特性。

添加 Linux 工作节点

Mon, 01 Jan 0001 00:00:00 +0000

本页介绍如何将 Linux 工作节点添加到 kubeadm 集群。

准备开始

每个要加入的工作节点都已安装安装 kubeadm 中所需的组件，例如 kubeadm、kubelet 和容器运行时。
一个正在运行的、由 kubeadm init 命令所创建的 kubeadm 集群，且该集群的创建遵循使用 kubeadm 创建集群文档中所给的步骤。
你需要对节点拥有超级用户权限。

添加 Linux 工作节点

要将新的 Linux 工作节点添加到集群中，请对每台机器执行以下步骤：

网络插件

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes（1.3 版本至最新 1.35，并可能包括未来版本）允许你使用容器网络接口（CNI）插件来完成集群联网。你必须使用和你的集群相兼容并且满足你的需求的 CNI 插件。在更广泛的 Kubernetes 生态系统中你可以使用不同的插件（开源和闭源）。

为集群超配节点容量

Mon, 01 Jan 0001 00:00:00 +0000

本页指导你在 Kubernetes 集群中配置节点超配。节点超配是一种主动预留部分集群计算资源的策略。这种预留有助于减少在扩缩容事件期间调度新 Pod 所需的时间，从而增强集群对突发流量或突发工作负载需求的响应能力。

为命名空间配置默认的内存请求和限制

Mon, 01 Jan 0001 00:00:00 +0000

本章介绍如何为命名空间配置默认的内存请求和限制。

为容器和 Pod 分配内存资源

Mon, 01 Jan 0001 00:00:00 +0000

此页面展示如何将内存请求（request）和内存限制（limit）分配给一个容器。我们保障容器拥有它请求数量的内存，但不允许使用超过限制数量的内存。

准备开始

为容器设置启动时要执行的命令和参数

Mon, 01 Jan 0001 00:00:00 +0000

本页将展示如何为 Pod 中容器设置启动时要执行的命令及其参数。

准备开始

限制范围（LimitRange）

Mon, 01 Jan 0001 00:00:00 +0000

默认情况下， Kubernetes 集群上的容器运行使用的计算资源没有限制。使用 Kubernetes 资源配额，管理员（也称为集群操作者）可以在一个指定的命名空间内限制集群资源的使用与创建。在命名空间中，一个 Pod 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。作为集群操作者或命名空间级的管理员，你可能也会担心如何确保一个 Pod 不会垄断命名空间内所有可用的资源。

以独立模式运行 kubelet

Mon, 01 Jan 0001 00:00:00 +0000

本教程将向你展示如何运行一个独立的 kubelet 实例。

用户认证

Mon, 01 Jan 0001 00:00:00 +0000

本页提供 Kubernetes 中身份认证有关的概述，重点介绍与 Kubernetes API 有关的身份认证。

Kubernetes 中的用户

所有 Kubernetes 集群都有两类用户：由 Kubernetes 管理的服务账号和普通用户。

云原生安全和 Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 基于云原生架构，并借鉴了 CNCF 有关云原生信息安全良好实践的建议。

运行多实例的应用

Mon, 01 Jan 0001 00:00:00 +0000

教程目标

使用 kubectl 手动扩缩现有的应用

扩缩应用

通过在使用 kubectl create deployment 命令时设置 --replicas 参数，你可以在启动 Deployment 时创建多个实例。

之前我们创建了一个 Deployment，然后通过 Service 让其可以公开访问。 Deployment 仅创建了一个 Pod 用于运行这个应用。当流量增加时，我们需要扩容应用满足用户需求。

在 Linux 系统中安装并设置 kubectl

Mon, 01 Jan 0001 00:00:00 +0000

准备开始

kubectl 版本和集群版本之间的差异必须在一个小版本号内。例如：v1.35 版本的客户端能与 v1.34、 v1.35 和 v1.36 版本的控制面通信。用最新兼容版的 kubectl 有助于避免不可预见的问题。

在 macOS 系统上安装和设置 kubectl

Mon, 01 Jan 0001 00:00:00 +0000

准备开始

kubectl 版本和集群之间的差异必须在一个小版本号之内。例如：v1.35 版本的客户端能与 v1.34、 v1.35 和 v1.36 版本的控制面通信。用最新兼容版本的 kubectl 有助于避免不可预见的问题。

在 Windows 上安装 kubectl

Mon, 01 Jan 0001 00:00:00 +0000

准备开始

在集群级别应用 Pod 安全标准

Mon, 01 Jan 0001 00:00:00 +0000

Note

本教程仅适用于新集群。

Pod 安全是一个准入控制器，当新的 Pod 被创建时，它会根据 Kubernetes Pod 安全标准进行检查。这是在 v1.25 中达到正式发布（GA）的功能。本教程将向你展示如何在集群级别实施 baseline Pod 安全标准，该标准将标准配置应用于集群中的所有名字空间。

在集群中安装 DRA

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.35 [stable]（默认启用）

本文介绍如何在 Kubernetes 集群中通过启用 API 组并配置设备类别来设置动态资源分配（DRA）。这些指示说明适用于集群管理员。

关于 DRA

Kubernetes 提供的一项特性，允许你在多个 Pod 之间请求和共享资源。
这些资源通常是挂接的设备，例如硬件加速器。

执行滚动更新

Mon, 01 Jan 0001 00:00:00 +0000

教程目标

使用 kubectl 执行滚动更新。

更新应用

滚动更新通过增量式更新 Pod 实例并替换为新的实例，允许在 Deployment 更新过程中实现零停机。

用户希望应用程序始终可用，而开发人员则需要每天多次部署它们的新版本。在 Kubernetes 中，这些是通过滚动更新（Rolling Update）完成的。 滚动更新允许通过使用新的实例逐步更新 Pod 实例，实现零停机的 Deployment 更新。新的 Pod 将被调度到具有可用资源的节点上。

CronJob

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: batch/v1

import "k8s.io/api/batch/v1"

CronJob

CronJob 代表单个定时作业（Cron Job）的配置。

apiVersion: batch/v1
kind: CronJob
metadata (ObjectMeta)

标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (CronJobSpec)

定时作业的预期行为的规约，包括排期表（Schedule）。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

ResourceFieldSelector

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/api/core/v1"

ResourceFieldSelector 表示容器资源（CPU，内存）及其输出格式。

resource (string)，必需

必需：选择的资源。
containerName (string)

容器名称：对卷必需，对环境变量可选。
divisor (Quantity)

指定所公开的资源的输出格式，默认值为 “1”。

VolumeAttachment

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

VolumeAttachment

VolumeAttachment 抓取将指定卷挂接到指定节点或从指定节点解除挂接指定卷的意图。

VolumeAttachment 对象未划分命名空间。

apiVersion: storage.k8s.io/v1
kind: VolumeAttachment

metadata (ObjectMeta)

常用参数

Mon, 01 Jan 0001 00:00:00 +0000

allowWatchBookmarks

allowWatchBookmarks 字段请求类型为 BOOKMARK 的监视事件。没有实现书签的服务器可能会忽略这个标志，并根据服务器的判断发送书签。客户端不应该假设书签会在任何特定的时间间隔返回，也不应该假设服务器会在会话期间发送任何书签事件。如果当前请求不是 watch 请求，则忽略该字段。

添加 Windows 工作节点

Mon, 01 Jan 0001 00:00:00 +0000

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

本页介绍如何将 Linux 工作节点添加到 kubeadm 集群。

准备开始

一个正在运行的 Windows Server 2022 （或更高版本）实例，且具备管理权限。
一个正在运行的、由 kubeadm init 命令创建的集群，且集群的创建遵循使用 kubeadm 创建集群文档中所给的步骤。

添加 Windows 工作节点

说明：

为了方便将 Windows 工作节点添加到集群，下面会用到代码仓库 https://sigs.k8s.io/sig-windows-tools 里的 PowerShell 脚本。

HorizontalPodAutoscaler

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: autoscaling/v1

import "k8s.io/api/autoscaling/v1"

HorizontalPodAutoscaler

水平 Pod 自动缩放器的配置。

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler

metadata (ObjectMeta)

标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

Status

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/apimachinery/pkg/apis/meta/v1"

状态（Status）是不返回其他对象的调用的返回值。

apiVersion (string)

apiVersion 定义对象表示的版本化模式。服务器应将已识别的模式转换为最新的内部值，并可能拒绝无法识别的值。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

VolumeAttributesClass

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

VolumeAttributesClass

VolumeAttributesClass 表示由 CSI 驱动所定义的可变更卷属性的规约。此类可以在动态制备 PersistentVolumeClaim 期间被指定，并且可以在制备之后在 PersistentVolumeClaim 规约中更改。

HorizontalPodAutoscaler

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: autoscaling/v2

import "k8s.io/api/autoscaling/v2"

HorizontalPodAutoscaler

HorizontalPodAutoscaler 是水平 Pod 自动扩缩器的配置，它根据指定的指标自动管理实现 scale 子资源的任何资源的副本数。

TypedLocalObjectReference

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/api/core/v1"

TypedLocalObjectReference 包含足够的信息，可以让你在同一个名称空间中定位特定类型的引用对象。

kind (string)，必需

PriorityClass

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: scheduling.k8s.io/v1

import "k8s.io/api/scheduling/v1"

PriorityClass

PriorityClass 定义了从优先级类名到优先级数值的映射。该值可以是任何有效的整数。

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass

metadata (ObjectMeta)

DeviceTaintRule v1alpha3

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: resource.k8s.io/v1alpha3

import "k8s.io/api/resource/v1alpha3"

DeviceTaintRule

DeviceTaintRule 添加一个污点到与选择算符匹配的所有设备上。这与通过 DRA 驱动直接在 ResourceSlice 中指定污点具有同样的效果。

Node 自动扩缩容

Mon, 01 Jan 0001 00:00:00 +0000

为了在集群中运行负载，你需要 Node。集群中的 Node 可以被自动扩缩容：通过动态制备或整合的方式提供所需的容量并优化成本。自动扩缩容操作是由 Node Autoscaler 执行的。

Pod 安全性标准

Mon, 01 Jan 0001 00:00:00 +0000

Pod 安全性标准定义了三种不同的策略（Policy），以广泛覆盖安全应用场景。这些策略是叠加式的（Cumulative），安全级别从高度宽松至高度受限。本指南概述了每个策略的要求。

Profile	描述
Privileged	不受限制的策略，提供最大可能范围的权限许可。此策略允许已知的特权提升。
Baseline	限制性最弱的策略，禁止已知的特权提升。允许使用默认的（规定最少）Pod 配置。
Restricted	限制性非常强的策略，遵循当前的保护 Pod 的最佳实践。

Profile 细节

Privileged

Privileged 策略是有目的地开放且完全无限制的策略。此类策略通常针对由特权较高、受信任的用户所管理的系统级或基础设施级负载。

安装一个扩展的 API server

Mon, 01 Jan 0001 00:00:00 +0000

安装扩展的 API 服务器来使用聚合层以让 Kubernetes API 服务器使用其它 API 进行扩展，这些 API 不是核心 Kubernetes API 的一部分。

准备开始

特性门控（已移除）

Mon, 01 Jan 0001 00:00:00 +0000

本页包含了已移除的特性门控的列表。本页的信息仅供参考。已移除的特性门控不同于正式发布（GA）或废弃的特性门控，因为已移除的特性门控将不再被视为有效的特性门控。然而，正式发布或废弃的特性门控仍然能被对应的 Kubernetes 组件识别，这些特性门控在集群中不会造成任何行为差异。

资源监控工具

Mon, 01 Jan 0001 00:00:00 +0000

要扩展应用程序并提供可靠的服务，你需要了解应用程序在部署时的行为。你可以通过检测容器、Pod、 Service 和整个集群的特征来检查 Kubernetes 集群中应用程序的性能。 Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细信息。此信息使你可以评估应用程序的性能，以及在何处可以消除瓶颈以提高整体性能。

资源指标管道

Mon, 01 Jan 0001 00:00:00 +0000

对于 Kubernetes，Metrics API 提供了一组基本的指标，以支持自动伸缩和类似的用例。该 API 提供有关节点和 Pod 的资源使用情况的信息，包括 CPU 和内存的指标。如果将 Metrics API 部署到集群中，那么 Kubernetes API 的客户端就可以查询这些信息，并且可以使用 Kubernetes 的访问控制机制来管理权限。

ResourceClaim v1beta2

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: resource.k8s.io/v1beta2

import "k8s.io/api/resource/v1beta2"

ResourceClaim

ResourceClaim 描述对集群中供工作负载使用的资源的访问请求。例如，如果某个工作负载需要具有特定属性的加速器设备，这就是表达该请求的方式。状态部分跟踪此申领是否已被满足，以及具体分配了哪些资源。

ResourceClaimTemplate v1beta2

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: resource.k8s.io/v1beta2

import "k8s.io/api/resource/v1beta2"

ResourceClaimTemplate

ResourceClaimTemplate 用于生成 ResourceClaim 对象。

这是一个 Alpha 类型的特性，需要启用 DynamicResourceAllocation 特性门控。

apiVersion: resource.k8s.io/v1beta2
kind: ResourceClaimTemplate
metadata (ObjectMeta)

标准的对象元数据。

ResourceSlice v1beta1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: resource.k8s.io/v1beta1

ResourceSlice v1alpha3

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: resource.k8s.io/v1alpha3

import "k8s.io/api/resource/v1alpha3"

ResourceSlice

ResourceSlice 表示一个或多个资源，这些资源位于同一个驱动所管理的、彼此相似的资源构成的资源池。一个池可以包含多个 ResourceSlice，一个池包含多少个 ResourceSlice 由驱动确定。

ConfigMap

Mon, 01 Jan 0001 00:00:00 +0000

ConfigMap 是一种 API 对象，用来将非机密性的数据保存到键值对中。使用时， Pod 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。

Issue 管理者

Mon, 01 Jan 0001 00:00:00 +0000

除了承担 PR 管理者的职责外， SIG Docs 正式的批准人（Approver）、评审人（Reviewer）和成员（Member）按周轮流归类仓库的 Issue。

职责

在为期一周的轮值期内，Issue 管理者每天负责：

kubeadm init

Mon, 01 Jan 0001 00:00:00 +0000

此命令初始化一个 Kubernetes 控制平面节点。

概要

运行此命令来搭建 Kubernetes 控制平面节点。

"init" 命令执行以下阶段：

preflight 预检
certs 生成证书
 /ca 生成自签名根 CA 用于配置其他 kubernetes 组件
 /apiserver 生成 apiserver 的证书
 /apiserver-kubelet-client 生成 apiserver 连接到 kubelet 的证书
 /front-proxy-ca 生成前端代理自签名 CA（扩展apiserver）
 /front-proxy-client 生成前端代理客户端的证书（扩展 apiserver）
 /etcd-ca 生成 etcd 自签名 CA
 /etcd-server 生成 etcd 服务器证书
 /etcd-peer 生成 etcd 节点相互通信的证书
 /etcd-healthcheck-client 生成 etcd 健康检查的证书
 /apiserver-etcd-client 生成 apiserver 访问 etcd 的证书
 /sa 生成用于签署服务帐户令牌的私钥和公钥
kubeconfig 生成建立控制平面和管理所需的所有 kubeconfig 文件
 /admin 生成一个 kubeconfig 文件供管理员使用以及供 kubeadm 本身使用
 /super-admin 为超级管理员生成 kubeconfig 文件
 /kubelet 为 kubelet 生成一个 kubeconfig 文件，*仅*用于集群引导
 /controller-manager 生成 kubeconfig 文件供控制器管理器使用
 /scheduler 生成 kubeconfig 文件供调度程序使用
etcd 为本地 etcd 生成静态 Pod 清单文件
 /local 为本地单节点本地 etcd 实例生成静态 Pod 清单文件
control-plane 生成建立控制平面所需的所有静态 Pod 清单文件
 /apiserver 生成 kube-apiserver 静态 Pod 清单
 /controller-manager 生成 kube-controller-manager 静态 Pod 清单
 /scheduler 生成 kube-scheduler 静态 Pod 清单
kubelet-start 写入 kubelet 设置并启动（或重启）kubelet
wait-control-plane 等待控制平面启动
upload-config 将 kubeadm 和 kubelet 配置上传到 ConfigMap
 /kubeadm 将 kubeadm 集群配置上传到 ConfigMap
 /kubelet 将 kubelet 组件配置上传到 ConfigMap
upload-certs 将证书上传到 kubeadm-certs
mark-control-plane 将节点标记为控制面
bootstrap-token 生成用于将节点加入集群的引导令牌
kubelet-finalize 在 TLS 引导后更新与 kubelet 相关的设置
addon 安装用于通过一致性测试所需的插件
 /coredns 将 CoreDNS 插件安装到 Kubernetes 集群
 /kube-proxy 将 kube-proxy 插件安装到 Kubernetes 集群
show-join-command 显示控制平面和工作节点的加入命令

kubeadm init [flags]

选项

--apiserver-advertise-address string

API 服务器所公布的其正在监听的 IP 地址。如果未设置，则使用默认网络接口。

kubectl 命令

Mon, 01 Jan 0001 00:00:00 +0000

kubectl 命令参考

kubelet

Mon, 01 Jan 0001 00:00:00 +0000

简介

kubelet 是在每个节点上运行的主要 “节点代理”。它可以使用以下方式之一向 API 服务器注册：

主机名（hostname）；
覆盖主机名的参数；
特定于某云驱动的逻辑。

kubelet 是基于 PodSpec 来工作的。每个 PodSpec 是一个描述 Pod 的 YAML 或 JSON 对象。 kubelet 接受通过各种机制（主要是通过 apiserver）提供的一组 PodSpec，并确保这些 PodSpec 中描述的容器处于运行状态且运行状况良好。 kubelet 不管理不是由 Kubernetes 创建的容器。

Kubernetes API 概念

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes API 是通过 HTTP 提供的基于资源 (RESTful) 的编程接口。它支持通过标准 HTTP 动词（POST、PUT、PATCH、DELETE、GET）检索、创建、更新和删除主要资源。

Kubernetes API 聚合层

Mon, 01 Jan 0001 00:00:00 +0000

使用聚合层（Aggregation Layer），用户可以通过附加的 API 扩展 Kubernetes，而不局限于 Kubernetes 核心 API 提供的功能。这里的附加 API 可以是现成的解决方案，比如 metrics server，或者你自己开发的 API。

Kubernetes 安全和信息披露

Mon, 01 Jan 0001 00:00:00 +0000

本页面介绍 Kubernetes 安全和信息披露相关的内容。

安全公告

加入 kubernetes-security-announce 组，以获取关于安全性和主要 API 公告的电子邮件。

报告一个漏洞

我们非常感谢向 Kubernetes 开源社区报告漏洞的安全研究人员和用户。所有的报告都由社区志愿者进行彻底调查。

Kubernetes 对象管理

Mon, 01 Jan 0001 00:00:00 +0000

kubectl 命令行工具支持多种不同的方式来创建和管理 Kubernetes 对象。本文档概述了不同的方法。阅读 Kubectl book 来了解 kubectl 管理对象的详细信息。

管理技巧

警告：

应该只使用一种技术来管理 Kubernetes 对象。混合和匹配技术作用在同一对象上将导致未定义行为。

Pod 安全性准入

Mon, 01 Jan 0001 00:00:00 +0000

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

Kubernetes Pod 安全性标准（Security Standard）为 Pod 定义不同的隔离级别。这些标准能够让你以一种清晰、一致的方式定义如何限制 Pod 行为。

PR 管理者

Mon, 01 Jan 0001 00:00:00 +0000

SIG Docs 的批准人（Approver）们每周轮流负责管理仓库的 PR。

本节介绍 PR 管理者的职责。关于如何提供较好的评审意见，可参阅评审变更。

职责

在为期一周的轮值期内，PR 管理者要：

ReplicaSet

Mon, 01 Jan 0001 00:00:00 +0000

ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。

持久卷

Mon, 01 Jan 0001 00:00:00 +0000

本文描述 Kubernetes 中的持久卷（Persistent Volumes）。建议先熟悉卷（Volume）、存储类（StorageClass）和卷属性类（VolumeAttributesClass）。

调度器配置

Mon, 01 Jan 0001 00:00:00 +0000

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

你可以通过编写配置文件，并将其路径传给 kube-scheduler 的命令行参数，定制 kube-scheduler 的行为。

调度模板（Profile）允许你配置 kube-scheduler 中的不同调度阶段。每个阶段都暴露于某个扩展点中。插件通过实现一个或多个扩展点来提供调度行为。

调试 Service

Mon, 01 Jan 0001 00:00:00 +0000

对于新安装的 Kubernetes，经常出现的问题是 Service 无法正常运行。你已经通过 Deployment（或其他工作负载控制器）运行了 Pod，并创建 Service ，但是当你尝试访问它时，没有任何响应。此文档有望对你有所帮助并找出问题所在。

定义相互依赖的环境变量

Mon, 01 Jan 0001 00:00:00 +0000

本页展示了如何为 Kubernetes Pod 中的容器定义相互依赖的环境变量。

准备开始

对 DaemonSet 执行回滚

Mon, 01 Jan 0001 00:00:00 +0000

本文展示了如何对 DaemonSet 执行回滚。

准备开始

对 kubeadm 进行故障排查

Mon, 01 Jan 0001 00:00:00 +0000

与任何程序一样，你可能会在安装或者运行 kubeadm 时遇到错误。本文列举了一些常见的故障场景，并提供可帮助你理解和解决这些问题的步骤。

访问集群

Mon, 01 Jan 0001 00:00:00 +0000

本文阐述多种与集群交互的方法。

使用 kubectl 完成集群的第一次访问

当你第一次访问 Kubernetes API 的时候，我们建议你使用 Kubernetes CLI 工具 kubectl。

Kubernetes 组件 SLI 指标

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.32 [stable]（默认启用）

默认情况下，Kubernetes 1.35 会为每个 Kubernetes 组件的二进制文件发布服务等级指标（SLI）。此指标端点被暴露在每个组件提供 HTTPS 服务的端口上，路径为 /metrics/slis。从 v1.27 版本开始，对每个 Kubernetes 组件而言， ComponentSLIs 特性门控都是默认启用的。

关于 dockershim 移除和使用兼容 CRI 运行时的文章

Mon, 01 Jan 0001 00:00:00 +0000

这是关于 Kubernetes 弃用和移除 dockershim 或使用兼容 CRI 的容器运行时相关的文章和其他页面的列表。

Kubernetes 项目

Kubernetes 博客：Dockershim 移除常见问题解答（最初发表于 2020/12/02）

将 Pod 指派给节点

Mon, 01 Jan 0001 00:00:00 +0000

你可以约束一个 Pod 以便限制其只能在特定的节点上运行，或优先在特定的节点上运行。有几种方法可以实现这点，推荐的方法都是用标签选择算符来进行选择。通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 Pod 分散到节点上，而不是将 Pod 放置在可用资源不足的节点上等等）。但在某些情况下，你可能需要进一步控制 Pod 被部署到哪个节点。例如，确保 Pod 最终落在连接了 SSD 的机器上，或者将来自两个不同的服务且有大量通信的 Pod 被放置在同一个可用区。

节点健康监测

Mon, 01 Jan 0001 00:00:00 +0000

节点问题检测器（Node Problem Detector） 是一个守护程序，用于监视和报告节点的健康状况。你可以将节点问题探测器以 DaemonSet 或独立守护程序运行。节点问题检测器从各种守护进程收集节点问题，并以节点 Condition 和 Event 的形式报告给 API 服务器。

节点与控制面之间的通信

Mon, 01 Jan 0001 00:00:00 +0000

本文列举控制面节点（确切地说是 API 服务器）和 Kubernetes 集群之间的通信路径。目的是为了让用户能够自定义他们的安装，以实现对网络配置的加固，使得集群能够在不可信的网络上（或者在一个云服务商完全公开的 IP 上）运行。

配置多个调度器

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 自带了一个默认调度器，其详细描述请查阅这里。如果默认调度器不适合你的需求，你可以实现自己的调度器。而且，你甚至可以和默认调度器一起同时运行多个调度器，并告诉 Kubernetes 为每个 Pod 使用哪个调度器。让我们通过一个例子讲述如何在 Kubernetes 中运行多个调度器。

评阅人和批准人文档

Mon, 01 Jan 0001 00:00:00 +0000

SIG Docs 评阅人（Reviewers）和批准人（Approvers）在对变更进行评审时需要做一些额外的事情。

容器环境

Mon, 01 Jan 0001 00:00:00 +0000

本页描述了在容器环境里容器可用的资源。

容器环境

Kubernetes 的容器环境给容器提供了几个重要的资源：

容器运行时

Mon, 01 Jan 0001 00:00:00 +0000

说明： 自 1.24 版起，Dockershim 已从 Kubernetes 项目中移除。阅读 Dockershim 移除的常见问题了解更多详情。

你需要在集群内每个节点上安装一个容器运行时以使 Pod 可以运行在上面。本文概述了所涉及的内容并描述了与节点设置相关的任务。

设备插件

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.26 [stable]

Kubernetes 提供了一个设备插件框架，你可以用它来将系统硬件资源发布到 Kubelet。

声明式 API 验证

Mon, 01 Jan 0001 00:00:00 +0000

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

Kubernetes 1.35 包含可选用于 API的声明式验证特性。当启用时，Kubernetes API 服务器可以使用此机制而不是依赖手写的 Go 代码（validation.go 文件）来确保针对 API 的请求是有效的。 Kubernetes 开发者和扩展 Kubernetes API 的人员可以直接在 API 类型定义（types.go 文件）旁边定义验证规则。代码作者定义特殊的注释标签（例如，+k8s:minimum=0）。然后，一个代码生成器（validation-gen）会使用这些标签来生成用于 API 验证的优化 Go 代码。

使用 Calico 提供 NetworkPolicy

Mon, 01 Jan 0001 00:00:00 +0000

本页展示了几种在 Kubernetes 上快速创建 Calico 集群的方法。

准备开始

确定你想部署一个云版本还是本地版本的集群。

在 Google Kubernetes Engine (GKE) 上创建一个 Calico 集群

先决条件：gcloud

使用 CustomResourceDefinition 扩展 Kubernetes API

Mon, 01 Jan 0001 00:00:00 +0000

本页展示如何使用 CustomResourceDefinition 将定制资源（Custom Resource）安装到 Kubernetes API 上。

准备开始

使用 DRA 为工作负载分配设备

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.35 [stable]（默认启用）

本文介绍如何使用动态资源分配（DRA） 为 Pod 分配设备。这些指示说明面向工作负载运维人员。在阅读本文之前，请先了解 DRA 的工作原理以及相关术语，例如 ResourceClaim 和 ResourceClaimTemplate。更多信息参阅动态资源分配（DRA）。

使用 Kustomize 对 Kubernetes 对象进行声明式管理

Mon, 01 Jan 0001 00:00:00 +0000

Kustomize 是一个独立的工具，用来通过 kustomization 文件定制 Kubernetes 对象。

从 1.14 版本开始，kubectl 也开始支持使用 kustomization 文件来管理 Kubernetes 对象。要查看包含 kustomization 文件的目录中的资源，执行下面的命令：

使用 Service 连接到应用

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 连接容器的模型

既然有了一个持续运行、可复制的应用，我们就能够将它暴露到网络上。

使用工作队列进行粗粒度并行处理

Mon, 01 Jan 0001 00:00:00 +0000

本例中，你将会运行包含多个并行工作进程的 Kubernetes Job。

使用配置文件管理 Secret

Mon, 01 Jan 0001 00:00:00 +0000

准备开始

使用启动引导令牌（Bootstrap Tokens）认证

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.18 [stable]

启动引导令牌是一种简单的持有者令牌（Bearer Token），这种令牌是在新建集群或者在现有集群中添加新节点时使用的。它被设计成能够支持 kubeadm，但是也可以被用在其他的案例中以便用户在不使用 kubeadm 的情况下启动集群。它也被设计成可以通过 RBAC 策略，结合 kubelet TLS 启动引导系统进行工作。

示例：使用 Redis 部署 PHP 留言板应用

Mon, 01 Jan 0001 00:00:00 +0000

本教程向你展示如何使用 Kubernetes 和 Docker 构建和部署一个简单的 (非面向生产的) 多层 Web 应用。本例由以下组件组成：

示例：使用持久卷部署 WordPress 和 MySQL

Mon, 01 Jan 0001 00:00:00 +0000

本示例描述了如何通过 Minikube 在 Kubernetes 上安装 WordPress 和 MySQL。这两个应用都使用 PersistentVolumes 和 PersistentVolumeClaims 保存数据。

提出内容改进建议

Mon, 01 Jan 0001 00:00:00 +0000

如果你发现 Kubernetes 文档中存在问题或者你有一个关于新内容的想法，可以考虑提出一个问题（issue）。你只需要具有 GitHub 账号和 Web 浏览器就可以完成这件事。

通过 ConfigMap 更新配置

Mon, 01 Jan 0001 00:00:00 +0000

本页提供了通过 ConfigMap 更新 Pod 中配置信息的分步示例，本教程的前置任务是配置 Pod 以使用 ConfigMap。在本教程结束时，你将了解如何变更运行中应用的配置。本教程以 alpine 和 nginx 镜像为例。

为发行版本撰写功能特性文档

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 的每个主要版本发布都会包含一些需要文档说明的新功能。新的发行版本也会更新已有的功能特性和文档（例如将某功能特性从 Alpha 升级为 Beta）。

为命名空间配置默认的 CPU 请求和限制

Mon, 01 Jan 0001 00:00:00 +0000

本章介绍如何为命名空间配置默认的 CPU 请求和限制。

为容器和 Pods 分配 CPU 资源

Mon, 01 Jan 0001 00:00:00 +0000

本页面展示如何为容器设置 CPU request（请求） 和 CPU limit（限制）。容器使用的 CPU 不能超过所配置的限制。如果系统有空闲的 CPU 时间，则可以保证给容器分配其所请求数量的 CPU 资源。

为容器设置环境变量

Mon, 01 Jan 0001 00:00:00 +0000

本页将展示如何为 Kubernetes Pod 下的容器设置环境变量。

准备开始

为上游 Kubernetes 代码库做出贡献

Mon, 01 Jan 0001 00:00:00 +0000

此页面描述如何为上游 kubernetes/kubernetes 项目做出贡献，如修复 Kubernetes API 文档或 Kubernetes 组件（例如 kubeadm、kube-apiserver、kube-controller-manager 等）中发现的错误。

如果你仅想从上游代码重新生成 Kubernetes API 或 kube-* 组件的参考文档。请参考以下说明：

运行一个单实例有状态应用

Mon, 01 Jan 0001 00:00:00 +0000

本文介绍在 Kubernetes 中如何使用 PersistentVolume 和 Deployment 运行一个单实例有状态应用。该示例应用是 MySQL。

教程目标

在你的环境中创建一个引用磁盘的 PersistentVolume。
创建一个 MySQL Deployment。
在集群内以一个已知的 DNS 名称将 MySQL 暴露给其他 Pod。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

运行于多可用区环境

Mon, 01 Jan 0001 00:00:00 +0000

本页描述如何跨多个区（Zone）运行集群。

背景

Kubernetes 从设计上允许同一个 Kubernetes 集群跨多个失效区来运行，通常这些区位于某个称作 区域（Region） 逻辑分组中。主要的云提供商都将区域定义为一组失效区的集合（也称作 可用区（Availability Zones）），能够提供一组一致的功能特性：每个区域内，各个可用区提供相同的 API 和服务。

在名字空间级别应用 Pod 安全标准

Mon, 01 Jan 0001 00:00:00 +0000

Note

本教程仅适用于新集群。

Pod Security Admission 是一个准入控制器，在创建 Pod 时应用 Pod 安全标准。这是在 v1.25 中达到正式发布（GA）的功能。在本教程中，你将应用 baseline Pod 安全标准，每次一个名字空间。

证书

Mon, 01 Jan 0001 00:00:00 +0000

要了解如何为集群生成证书，参阅证书。

资源配额

Mon, 01 Jan 0001 00:00:00 +0000

当多个用户或团队共享具有固定节点数目的集群时，人们会担心有人使用超过其基于公平原则所分配到的资源量。

资源配额是帮助管理员解决这一问题的工具。

资源配额，由 ResourceQuota 对象定义，提供了限制每个命名空间的资源总消耗的约束。资源配额还可以限制在命名空间中可以创建的对象数量（按 API 类型计算），以及该命名空间中存在的 API 对象可能消耗的基础设施资源的总量。

投射卷

Mon, 01 Jan 0001 00:00:00 +0000

本文档描述 Kubernetes 中的投射卷（Projected Volume）。建议先熟悉卷概念。

介绍

一个 projected 卷可以将若干现有的卷源映射到同一个目录之上。

官方 CVE 订阅源

Mon, 01 Jan 0001 00:00:00 +0000

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

这是由 Kubernetes 安全响应委员会（Security Response Committee, SRC）公布的经社区维护的官方 CVE 列表。更多细节请参阅 Kubernetes 安全和信息披露。

服务器端应用（Server-Side Apply）

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.22 [stable]（默认启用）

Kubernetes 支持多个应用程序协作管理一个对象的字段。服务器端应用为集群的控制平面提供了一种可选机制，用于跟踪对对象字段的更改。在特定资源级别，服务器端应用记录并跟踪有关控制该对象字段的信息。

服务账号

Mon, 01 Jan 0001 00:00:00 +0000

本页介绍 Kubernetes 中的 ServiceAccount 对象，讲述服务账号的工作原理、使用场景、限制、替代方案，还提供了一些资源链接方便查阅更多指导信息。

什么是服务账号？

服务账号是在 Kubernetes 中一种用于非人类用户的账号，在 Kubernetes 集群中提供不同的身份标识。应用 Pod、系统组件以及集群内外的实体可以使用特定 ServiceAccount 的凭据来将自己标识为该 ServiceAccount。这种身份可用于许多场景，包括向 API 服务器进行身份认证或实现基于身份的安全策略。

CustomResourceDefinition 的版本

Mon, 01 Jan 0001 00:00:00 +0000

本页介绍如何添加版本信息到 CustomResourceDefinitions。目的是标明 CustomResourceDefinitions 的稳定级别或者服务于 API 升级。 API 升级时需要在不同 API 表示形式之间进行转换。本页还描述如何将对象从一个版本升级到另一个版本。

Ingress

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.19 [stable]

Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。

kube-apiserver

Mon, 01 Jan 0001 00:00:00 +0000

简介

Kubernetes API 服务器验证并配置 API 对象的数据，这些对象包括 pods、services、replicationcontrollers 等。 API 服务器为 REST 操作提供服务，并为集群的共享状态提供前端，所有其他组件都通过该前端进行交互。

kube-apiserver [flags]

选项

--admission-control strings

准入过程分为两个阶段。第一阶段仅运行变更型准入插件。第二阶段仅运行验证型准入插件。以下列表中的名称可能代表验证型插件、变更型插件或两者兼有。传递给此标志的插件顺序无关紧要。以逗号分隔的列表： AlwaysAdmit、AlwaysDeny、AlwaysPullImages、CertificateApproval、 CertificateSigning、CertificateSubjectRestriction、 ClusterTrustBundleAttest、DefaultIngressClass、DefaultStorageClass、 DefaultTolerationSeconds、DenyServiceExternalIPs、EventRateLimit、 ExtendedResourceToleration、ImagePolicyWebhook、LimitPodHardAntiAffinityTopology、 LimitRanger、MutatingAdmissionPolicy、MutatingAdmissionWebhook、NamespaceAutoProvision、 NamespaceExists、NamespaceLifecycle、NodeDeclaredFeatureValidator、NodeRestriction、 OwnerReferencesPermissionEnforcement、PersistentVolumeClaimResize、PodNodeSelector、 PodSecurity、PodTolerationRestriction、PodTopologyLabels、Priority、ResourceQuota、 RuntimeClass、ServiceAccount、StorageObjectInUseProtection TaintNodesByCondition、 ValidatingAdmissionPolicy、ValidatingAdmissionWebhook。（已弃用：请改用 --enable-admission-plugins 或 --disable-admission-plugins。将在未来版本中移除。）

kube-controller-manager

Mon, 01 Jan 0001 00:00:00 +0000

简介

Kubernetes 控制器管理器是一个守护进程，内嵌随 Kubernetes 一起发布的核心控制回路。在机器人和自动化的应用中，控制回路是一个永不休止的循环，用于调节系统状态。在 Kubernetes 中，每个控制器是一个控制回路，通过 API 服务器监视集群的共享状态，并尝试进行更改以将当前状态转为期望状态。目前，Kubernetes 自带的控制器例子包括副本控制器、节点控制器、命名空间控制器和服务账号控制器等。

kube-proxy

Mon, 01 Jan 0001 00:00:00 +0000

简介

Kubernetes 网络代理在每个节点上运行。网络代理反映了每个节点上 Kubernetes API 中定义的服务，并且可以执行简单的 TCP、UDP 和 SCTP 流转发，或者在一组后端进行循环 TCP、UDP 和 SCTP 转发。当前可通过 Docker-links-compatible 环境变量找到服务集群 IP 和端口，这些环境变量指定了服务代理打开的端口。有一个可选的插件，可以为这些集群 IP 提供集群 DNS。用户必须使用 apiserver API 创建服务才能配置代理。

kube-scheduler

Mon, 01 Jan 0001 00:00:00 +0000

简介

Kubernetes 调度器是一个控制面进程，负责将 Pods 指派到节点上。调度器基于约束和可用资源为调度队列中每个 Pod 确定其可合法放置的节点。调度器之后对所有合法的节点进行排序，将 Pod 绑定到一个合适的节点。在同一个集群中可以使用多个不同的调度器；kube-scheduler 是其参考实现。参阅调度以获得关于调度和 kube-scheduler 组件的更多信息。

kubeadm join

Mon, 01 Jan 0001 00:00:00 +0000

此命令用来初始化新的 Kubernetes 节点并将其加入集群。

在你希望加入现有集群的任何机器上运行它。

概要

当节点加入 kubeadm 初始化的集群时，我们需要建立双向信任。这个过程可以分解为发现（让待加入节点信任 Kubernetes 控制平面节点）和 TLS 引导（让 Kubernetes 控制平面节点信任待加入节点）两个部分。

kubectl

Mon, 01 Jan 0001 00:00:00 +0000

简介

kubectl 用于控制 Kubernetes 集群管理器。

参阅更多细节： https://kubernetes.io/zh-cn/docs/reference/kubectl/

kubectl [flags]

选项

--as string

操作所用的伪装用户名。用户可以是常规用户或命名空间中的服务账号。

--as-group strings

操作所用的伪装用户组，此标志可以被重复设置以指定多个组。

kubectl

Mon, 01 Jan 0001 00:00:00 +0000

简介

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_EXPLAIN_OPENAPIV3
	切换对 `kubectl explain` 的调用是否使用可用的新 OpenAPIv3 数据源。 OpenAPIV3 自 Kubernetes 1.24 起默认被启用。
KUBECTL_ENABLE_CMD_SHADOW
	当设置为 true 时，如果子命令不存在，外部插件可以用作内置命令的子命令。此功能处于 alpha 阶段，只能用于 create 命令（例如 `kubectl create networkpolicy`）。
KUBECTL_PORT_FORWARD_WEBSOCKETS
	当设置为 true 时，`kubectl port-forward` 命令将尝试使用 WebSocket 协议进行流式传输。如果升级到 WebSocket 失败，命令将回退到使用当前的 SPDY 协议。
KUBECTL_REMOTE_COMMAND_WEBSOCKETS
	当设置为 true 时，kubectl exec、cp 和 attach 命令将尝试使用 WebSocket 协议进行流式传输。如果升级到 WebSocket 失败，这些命令将回退为使用当前的 SPDY 协议。
KUBECTL_KUBERC
	当设置为 true 时，kuberc 文件会被纳入考虑，用于定义用户特定偏好设置。
KUBECTL_KYAML
	当设置为 true 时，kubectl 可以生成 Kubernetes 特定的 YAML 输出格式。

另请参见

kubectl annotate - 更新资源所关联的注解
kubectl api-resources - 打印服务器上所支持的 API 资源
kubectl api-versions - 以“组/版本”的格式输出服务端所支持的 API 版本
kubectl apply - 基于文件名或标准输入，将新的配置应用到资源上
kubectl attach - 挂接到一个正在运行的容器

kubectl auth - 检查授权信息
kubectl autoscale - 对一个资源对象（Deployment、ReplicaSet 或 ReplicationController）进行自动扩缩
kubectl certificate - 修改证书资源
kubectl cluster-info - 显示集群信息
kubectl completion - 根据已经给出的 Shell（bash 或 zsh），输出 Shell 补全后的代码
kubectl config - 修改 kubeconfig 配置文件

kubectl cordon - 标记节点为不可调度的
kubectl cp - 将文件和目录拷入/拷出容器
kubectl create - 通过文件或标准输入来创建资源
kubectl debug - 创建用于排查工作负载和节点故障的调试会话
kubectl delete - 通过文件名、标准输入、资源和名字删除资源，或者通过资源和标签选择算符来删除资源

kubectl describe - 显示某个资源或某组资源的详细信息
kubectl diff - 显示目前版本与将要应用的版本之间的差异
kubectl drain - 腾空节点，准备维护
kubectl edit - 修改服务器上的某资源
kubectl events - 列举事件
kubectl exec - 在容器中执行相关命令
kubectl explain - 显示资源文档说明
kubectl expose - 给定副本控制器、服务、Deployment 或 Pod，将其暴露为新的 kubernetes Service

kubectl get - 显示一个或者多个资源信息
kubectl kustomize - 从目录或远程 URL 中构建 kustomization
kubectl label - 更新资源的标签
kubectl logs - 输出 Pod 中某容器的日志
kubectl options - 打印所有命令都支持的共有参数列表
kubectl patch - 更新某资源中的字段

kubectl plugin - 运行命令行插件
kubectl port-forward - 将一个或者多个本地端口转发到 Pod
kubectl proxy - 运行一个 kubernetes API 服务器代理
kubectl replace - 基于文件名或标准输入替换资源
kubectl rollout - 管理资源的上线
kubectl run - 在集群中使用指定镜像启动容器

kubectl scale - 为一个 Deployment、ReplicaSet 或 ReplicationController 设置一个新的规模值
kubectl set - 为对象设置功能特性
kubectl taint - 在一个或者多个节点上更新污点配置
kubectl top - 显示资源（CPU/内存/存储）使用率
kubectl uncordon - 标记节点为可调度的
kubectl version - 打印客户端和服务器的版本信息
kubectl wait - 实验级特性：等待一个或多个资源达到某种状态

kubectl apply edit-last-applied

Mon, 01 Jan 0001 00:00:00 +0000

简介

使用默认编辑器编辑资源的最新的 last-applied-configuration 注解。

kubectl apply set-last-applied

Mon, 01 Jan 0001 00:00:00 +0000

简介

设置 last-applied-configuration 注解使之与某文件内容相匹配。这会导致 last-applied-configuration 被更新，就像运行了 kubectl apply -f <file> 一样，但是不会更新对象的任何其他部分。

kubectl apply set-last-applied -f FILENAME

示例

# 设置资源的 last-applied-configuration，使之与某文件内容相同
kubectl apply set-last-applied -f deploy.yaml
 
# 针对目录中的每一个配置文件执行 set-last-applied 操作
kubectl apply set-last-applied -f path/
 
# 设置资源的 last-applied-configuration 注解，使之与某文件内容匹配；如果该注解尚不存在，则会被创建。
kubectl apply set-last-applied -f deploy.yaml --create-annotation=true

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl apply view-last-applied

Mon, 01 Jan 0001 00:00:00 +0000

简介

根据所给类别/名称或文件来查看最新的 last-applied-configuration 注解。

默认输出将以 YAML 格式打印到标准输出。你可以使用 -o 选项来更改输出格式。

kubectl apply view-last-applied (TYPE [NAME | -l label] | TYPE/NAME | -f FILENAME)

示例

# 根据所给类别/名称以 YAML 格式查看 last-applied-configuration 注解
kubectl apply view-last-applied deployment/nginx
 
# 根据所给文件以 JSON 格式查看 last-applied-configuration 注解
kubectl apply view-last-applied -f deploy.yaml -o json

选项

--all

选择指定资源类型的命名空间中的所有资源。

kubectl auth can-i

Mon, 01 Jan 0001 00:00:00 +0000

简介

检查某个操作是否被允许。

kubectl auth reconcile

Mon, 01 Jan 0001 00:00:00 +0000

简介

调和 RBAC 角色、角色绑定、集群角色和集群角色绑定对象的规则。

kubectl auth whoami

Mon, 01 Jan 0001 00:00:00 +0000

简介

实验性功能：检查你的身份和属性（如所属的组、额外信息等）。

此命令有助于让你了解当前用户属性，尤其是在 Kubernetes 集群中启用动态身份验证（例如令牌 Webhook、身份认证代理或 OIDC 提供程序）时。

kubectl auth whoami

示例

# 获取你的主体属性
kubectl auth whoami
 
# 以 JSON 格式获取主体属性
kubectl auth whoami -o json

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl certificate approve

Mon, 01 Jan 0001 00:00:00 +0000

简介

批准证书签名请求。

kubectl certificate deny

Mon, 01 Jan 0001 00:00:00 +0000

简介

拒绝证书签名请求。

kubectl certificate deny 允许集群管理员拒绝证书签名请求 (CSR)。此操作通知证书签名控制器不向请求者颁发证书。

kubectl certificate deny (-f FILENAME | NAME)

示例

# 拒绝 CSR 'csr-sqgzp'
kubectl certificate deny csr-sqgzp

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl cluster-info dump

Mon, 01 Jan 0001 00:00:00 +0000

简介

转储集群信息，适合于调试和诊断集群问题。默认情况下，将所有内容转储到 stdout。你可以使用 --output-directory 指定目录。如果指定目录，Kubernetes 将在该目录中构建一组文件。默认情况下，仅转储当前命名空间和 "kube-system" 命名空间中的内容，但你也可以使用 --namespaces 标志切换到其他命名空间，或指定 --all-namespaces 以转储所有命名空间。

kubectl config current-context

Mon, 01 Jan 0001 00:00:00 +0000

简介

显示当前上下文。

kubectl config current-context [flags]

示例

# 显示当前上下文
kubectl config current-context

选项

-h, --help
	关于 current-context 的帮助信息。

继承于父命令的选项

--as string

操作所用的伪装用户名。用户可以是常规用户或命名空间中的服务账号。

kubectl config delete-cluster

Mon, 01 Jan 0001 00:00:00 +0000

简介

从 kubeconfig 中删除指定的集群。

kubectl config delete-cluster NAME

示例

# 删除 minikube 集群
kubectl config delete-cluster minikube

选项

-h, --help
	关于 delete-cluster 的帮助信息。

继承于父命令的选项

--as string

操作所用的伪装用户名。用户可以是常规用户或命名空间中的服务账号。

kubectl config delete-context

Mon, 01 Jan 0001 00:00:00 +0000

简介

从 kubeconfig 中删除指定的上下文。

kubectl config delete-context NAME

示例

# 删除 minikube 集群的上下文
kubectl config delete-context minikube

选项

-h, --help
	关于 delete-context 的帮助信息。

继承于父命令的选项

--as string

操作所用的伪装用户名。用户可以是常规用户或命名空间中的服务账号。

kubectl config delete-user

Mon, 01 Jan 0001 00:00:00 +0000

简介

从 kubeconfig 中删除指定用户。

kubectl config delete-user NAME

示例

# 删除 minikube 用户
kubectl config delete-user minikube

选项

-h, --help

关于 delete-user 的帮助信息。

kubectl config get-clusters

Mon, 01 Jan 0001 00:00:00 +0000

简介

显示 kubeconfig 中定义的集群。

kubectl config get-clusters [flags]

示例

# 列出 kubectl 所知悉的集群
kubectl config get-clusters

选项

-h, --help
	关于 get-clusters 的帮助信息。

继承于父命令的选项

--as string

操作所用的伪装用户名。用户可以是常规用户或命名空间中的服务账号。

kubectl config get-contexts

Mon, 01 Jan 0001 00:00:00 +0000

简介

显示 kubeconfig 文件中的一个或多个上下文。

kubectl config get-contexts [(-o|--output=)name)]

示例

# 列出 kubeconfig 文件中的所有上下文
kubectl config get-contexts
 
# 描述 kubeconfig 文件中指定上下文的详细信息
kubectl config get-contexts my-context

选项

-h, --help

关于 get-contexts 的帮助信息。

kubectl config get-users

Mon, 01 Jan 0001 00:00:00 +0000

简介

显示 kubeconfig 中定义的用户。

kubectl config get-users [flags]

示例

# 列出 kubectl 知悉的用户
kubectl config get-users

选项

-h, --help
	关于 get-users 的帮助信息。

继承于父命令的选项

--as string

操作所用的伪装用户名。用户可以是常规用户或命名空间中的服务账号。

kubectl config rename-context

Mon, 01 Jan 0001 00:00:00 +0000

简介

重命名 kubeconfig 文件中的上下文。

CONTEXT_NAME 是要更改的上下文名称。
NEW_NAME 是要设置的新名称。

注意：如果重命名的上下文是“当前上下文”，则该字段也将被更新。

kubectl config rename-context CONTEXT_NAME NEW_NAME

示例

# 将 kubeconfig 文件中上下文 "old-name" 重命名为 "new-name"
kubectl config rename-context old-name new-name

选项

-h, --help

关于 rename-context 的帮助信息。

kubectl config set

Mon, 01 Jan 0001 00:00:00 +0000

简介

设置 kubeconfig 文件中的单个值。

kubectl config set-cluster

Mon, 01 Jan 0001 00:00:00 +0000

简介

设置 kubeconfig 中的集群条目。

指定已存在的属性名称将把新字段值与现有值合并。

kubectl config set-cluster NAME [--server=server] [--certificate-authority=path/to/certificate/authority] [--insecure-skip-tls-verify=true] [--tls-server-name=example.com]

示例

# 仅设置 e2e 集群条目上的 server 字段，不触及其他值
kubectl config set-cluster e2e --server=https://1.2.3.4
 
# 在 e2e 集群条目中嵌入证书颁发机构的数据
kubectl config set-cluster e2e --embed-certs --certificate-authority=~/.kube/e2e/kubernetes.ca.crt
 
# 禁用 e2e 集群条目中的证书检查
kubectl config set-cluster e2e --insecure-skip-tls-verify=true
 
# 设置用于验证 e2e 集群条目的自定义 TLS 服务器名称
kubectl config set-cluster e2e --tls-server-name=my-cluster-name
 
# 设置 e2e 集群条目的代理 URL
kubectl config set-cluster e2e --proxy-url=https://1.2.3.4

选项

--certificate-authority string

kubeconfig 中集群条目的证书颁发机构文件的路径。

kubectl config set-context

Mon, 01 Jan 0001 00:00:00 +0000

简介

在 kubeconfig 中设置上下文条目。

指定已存在的属性名称将把新字段值与现有值合并。

kubectl config set-context [NAME | --current] [--cluster=cluster_nickname] [--user=user_nickname] [--namespace=namespace]

示例

# 在 gce 上下文条目上设置用户字段，而不影响其他值
kubectl config set-context gce --user=cluster-admin

选项

--cluster string

kubeconfig 中上下文条目的集群。

kubectl config set-credentials

Mon, 01 Jan 0001 00:00:00 +0000

简介

在 kubeconfig 中设置用户条目。

指定已存在的属性名称将把新字段值与现有值合并。
- 客户端证书标志：--client-certificate=certfile --client-key=keyfile
- 持有者令牌标志：--token=bearer_token
- 基本身份验证标志：--username=basic_user --password=basic_password
持有者令牌和基本身份验证是互斥的（不可同时使用）。

kubectl config set-credentials NAME [--client-certificate=path/to/certfile] [--client-key=path/to/keyfile] [--token=bearer_token] [--username=basic_user] [--password=basic_password] [--auth-provider=provider_name] [--auth-provider-arg=key=value] [--exec-command=exec_command] [--exec-api-version=exec_api_version] [--exec-arg=arg] [--exec-env=key=value]

示例

# 仅设置 "cluster-admin" 条目上的 "client-key" 字段，不触及其他值
kubectl config set-credentials cluster-admin --client-key=~/.kube/admin.key
 
# 为 "cluster-admin" 条目设置基本身份验证
kubectl config set-credentials cluster-admin --username=admin --password=uXFGweU9l35qcif
 
# 在 "cluster-admin" 条目中嵌入客户端证书数据
kubectl config set-credentials cluster-admin --client-certificate=~/.kube/admin.crt --embed-certs=true
 
# 为 "cluster-admin" 条目启用 Google Compute Platform 身份认证提供程序
kubectl config set-credentials cluster-admin --auth-provider=gcp
 
# 使用附加参数为 "cluster-admin" 条目启用 OpenID Connect 身份认证提供程序
kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-id=foo --auth-provider-arg=client-secret=bar
 
# 删除 "cluster-admin" 条目的 OpenID Connect 身份验证提供程序的 "client-secret" 配置值
kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-secret-
 
# 为 "cluster-admin" 条目启用新的 exec 认证插件
kubectl config set-credentials cluster-admin --exec-command=/path/to/the/executable --exec-api-version=client.authentication.k8s.io/v1beta1
 
# 为 "cluster-admin" 条目启用新的、带交互模式的 exec 认证插件
kubectl config set-credentials cluster-admin --exec-command=/path/to/the/executable --exec-api-version=client.authentication.k8s.io/v1beta1 --exec-interactive-mode=Never
 
# 为 "cluster-admin" 条目定义新的 exec 认证插件参数
kubectl config set-credentials cluster-admin --exec-arg=arg1 --exec-arg=arg2
 
# 为 "cluster-admin" 条目创建或更新 exec 认证插件环境变量
kubectl config set-credentials cluster-admin --exec-env=key1=val1 --exec-env=key2=val2
 
# 删除 "cluster-admin" 条目的 exec 认证插件环境变量
kubectl config set-credentials cluster-admin --exec-env=var-to-remove-

选项

--auth-provider string

kubeconfig 中用户条目的身份验证提供程序。

kubectl config unset

Mon, 01 Jan 0001 00:00:00 +0000

简介

去除 kubeconfig 文件中的某个值的设置。

PROPERTY_NAME 是一个以点分隔的名称，其中每个元素代表一个属性名称或一个键名。键名不得包含点。

kubectl config unset PROPERTY_NAME

示例

# 去除 current-context 设置
kubectl config unset current-context
 
# 去掉 foo 上下文中的 namespace 设置
kubectl config unset contexts.foo.namespace

选项

-h, --help

关于 unset 的帮助信息。

kubectl config use-context

Mon, 01 Jan 0001 00:00:00 +0000

简介

在 kubeconfig 文件中设置当前上下文。

kubectl config use-context CONTEXT_NAME

示例

# 使用 minikube 集群的上下文
kubectl config use-context minikube

选项

-h, --help
	关于 use-context 的帮助信息。

继承于父命令的选项

--as string

操作所用的伪装用户名。用户可以是常规用户或命名空间中的服务账号。

kubectl config view

Mon, 01 Jan 0001 00:00:00 +0000

简介

显示合并的 kubeconfig 配置或指定的 kubeconfig 文件。

你可以使用 --output jsonpath={...} 通过 jsonpath 表达式提取特定值。

kubectl config view [flags]

示例

# 显示合并的 kubeconfig 设置
kubectl config view
 
# 显示合并的 kubeconfig 设置、原始证书数据和公开的密钥
kubectl config view --raw
 
# 获取 e2e 用户的密码
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create clusterrole

Mon, 01 Jan 0001 00:00:00 +0000

简介

创建一个集群角色。

kubectl create clusterrole NAME --verb=verb --resource=resource.group [--resource-name=resourcename] [--dry-run=server|client|none]

示例

 # 创建一个名为 "pod-reader" 的集群角色，允许用户对 Pod 执行 "get"、"watch" 和 "list" 操作
 kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
 
 # 创建一个名为 "pod-reader" 的集群角色，并指定 ResourceName
 kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
 
 # 创建一个名为 "foo" 的集群角色，并指定 API 组
 kubectl create clusterrole foo --verb=get,list,watch --resource=rs.apps
 
 # 创建一个名为 "foo" 的集群角色，并指定 SubResource
 kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
 
 # 创建一个名为 "foo" 的集群角色，并指定 NonResourceURL
 kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
 
 # 创建一个名为 "monitoring" 的集群角色，并指定 AggregationRule
 kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"

选项

--aggregation-rule <英文逗号分隔的 'key=value' 对>

用于组合 ClusterRole 的聚合标签选择算符。

kubectl create clusterrolebinding

Mon, 01 Jan 0001 00:00:00 +0000

简介

为特定的集群角色创建一个集群角色绑定。

kubectl create clusterrolebinding NAME --clusterrole=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]

示例

# 使用 cluster-admin 集群角色为 user1、user2 和 group1 创建一个集群角色绑定
kubectl create clusterrolebinding cluster-admin --clusterrole=cluster-admin --user=user1 --user=user2 --group=group1

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create configmap

Mon, 01 Jan 0001 00:00:00 +0000

简介

基于文件、目录或指定的文字值创建 ConfigMap。

kubectl create cronjob

Mon, 01 Jan 0001 00:00:00 +0000

简介

创建具有指定名称的 CronJob。

kubectl create cronjob NAME --image=image --schedule='0/5 * * * ?' -- [COMMAND] [args...] [flags]

示例

# 创建 CronJob
kubectl create cronjob my-job --image=busybox --schedule="*/1 * * * *"
 
# 创建带有命令的 CronJob
kubectl create cronjob my-job --image=busybox --schedule="*/1 * * * *" -- date

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create deployment

Mon, 01 Jan 0001 00:00:00 +0000

简介

创建指定名称的 Deployment。

kubectl create deployment NAME --image=image -- [COMMAND] [args...]

示例

# 创建一个名为 my-dep 的 Deployment，它将运行 busybox 镜像
kubectl create deployment my-dep --image=busybox

# 创建一个带有命令的 Deployment
kubectl create deployment my-dep --image=busybox -- date

# 创建一个名为 my-dep 的 Deployment，它将运行 nginx 镜像并有 3 个副本
kubectl create deployment my-dep --image=nginx --replicas=3

# 创建一个名为 my-dep 的 Deployment，它将运行 busybox 镜像并公开端口 5701
kubectl create deployment my-dep --image=busybox --port=5701

# 创建一个名为 my-dep 的 Deployment，它将运行多个容器
kubectl create deployment my-dep --image=busybox:latest --image=ubuntu:latest --image=nginx

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create ingress

Mon, 01 Jan 0001 00:00:00 +0000

简介

创建指定名称的 Ingress。

kubectl create ingress NAME --rule=host/path=service:port[,tls[=secret]]

示例

# 创建一个名为 'simple' 的 Ingress，使用 TLS 类别 Secret "my-cert"
# 将针对 foo.com/bar 的请求重定向到 svc1:8080
kubectl create ingress simple --rule="foo.com/bar=svc1:8080,tls=my-cert"
 
# 创建一个 Ingress，获取指向服务 svc:port 的所有 "/path" 请求，并将 Ingress Class 设置为 "otheringress"
kubectl create ingress catch-all --class=otheringress --rule="/path=svc:port"

# 创建含两个注解 ingress.annotation1 和 ingress.annotation2 的 Ingress
kubectl create ingress annotated --class=default --rule="foo.com/bar=svc:port" \
 --annotation ingress.annotation1=foo \
 --annotation ingress.annotation2=bla
 
# 创建具有相同主机和多个路径的 Ingress
kubectl create ingress multipath --class=default \
 --rule="foo.com/=svc:port" \
 --rule="foo.com/admin/=svcadmin:portadmin"
 
# 创建具有多个主机且 pathType 为 Prefix 的 Ingress
kubectl create ingress ingress1 --class=default \
 --rule="foo.com/path*=svc:8080" \
 --rule="bar.com/admin*=svc2:http"
 
# 创建使用默认 Ingress 证书来启用 TLS 且具备不同路径类型的 Ingress
kubectl create ingress ingtls --class=default \
 --rule="foo.com/=svc:https,tls" \
 --rule="foo.com/path/subpath*=othersvc:8080"
 
# 创建使用特定密钥来启用 TLS 且 pathType 为 Prefix 的 Ingress
kubectl create ingress ingsecret --class=default \
 --rule="foo.com/*=svc:8080,tls=secret1"
 
# 创建具有默认后端的 Ingress
kubectl create ingress ingdefault --class=default \
 --default-backend=defaultsvc:http \
 --rule="foo.com/*=svc:8080,tls=secret1"

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create job

Mon, 01 Jan 0001 00:00:00 +0000

简介

创建指定名称的 Job。

kubectl create job NAME --image=image [--from=cronjob/name] -- [COMMAND] [args...]

示例

# 创建一个 Job
kubectl create job my-job --image=busybox
 
# 创建带一条命令的 Job
kubectl create job my-job --image=busybox -- date

# 从名为 "a-cronjob" 的定时任务创建一个 Job
kubectl create job test-job --from=cronjob/a-cronjob

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create namespace

Mon, 01 Jan 0001 00:00:00 +0000

简介

用指定的名称创建命名空间。

kubectl create namespace NAME [--dry-run=server|client|none]

示例

# 新建一个名为 my-namespace 的命名空间
kubectl create namespace my-namespace

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create poddisruptionbudget

Mon, 01 Jan 0001 00:00:00 +0000

简介

创建具有指定名称、选择算符和预期最少可用 Pod 个数的 Pod 干扰预算。

kubectl create poddisruptionbudget NAME --selector=SELECTOR --min-available=N [--dry-run=server|client|none]

示例

# 创建一个名为 my-pdb 的 Pod 干扰预算，它将选择所有带有 app=rails 标签的 Pod
# 并要求至少有一个 Pod 在任何时候都是可用的
kubectl create poddisruptionbudget my-pdb --selector=app=rails --min-available=1

# 创建一个名为 my-pdb 的 Pod 干扰预算，它将选择所有带有 app=nginx 标签的 Pod
# 并要求在任何时候所选 Pod 中至少有一半是可用的
kubectl create pdb my-pdb --selector=app=nginx --min-available=50%

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create priorityclass

Mon, 01 Jan 0001 00:00:00 +0000

简介

创建带有指定名称、取值、globalDefault 设置及描述的优先级类对象。

kubectl create priorityclass NAME --value=VALUE --global-default=BOOL [--dry-run=server|client|none]

示例

# 创建一个名为 high-priority 的优先级类
kubectl create priorityclass high-priority --value=1000 --description="high priority"
 
# 创建一个名为 default-priority 的优先级类，并将其视为全局默认优先级
kubectl create priorityclass default-priority --value=1000 --global-default=true --description="default priority"
 
# 创建一个名为 high-priority 的优先级类，它不能抢占低优先级的 Pod
kubectl create priorityclass high-priority --value=1000 --description="high priority" --preemption-policy="Never"

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create quota

Mon, 01 Jan 0001 00:00:00 +0000

简介

创建具有指定名称、硬性限制和可选范围的资源配额。

kubectl create quota NAME [--hard=key1=value1,key2=value2] [--scopes=Scope1,Scope2] [--dry-run=server|client|none]

示例

# 新建一个名为 my-quota 的资源配额
kubectl create quota my-quota --hard=cpu=1,memory=1G,pods=2,services=3,replicationcontrollers=2,resourcequotas=1,secrets=5,persistentvolumeclaims=10
 
# 新建一个名为 best-effort 的资源配额
kubectl create quota best-effort --hard=pods=100 --scopes=BestEffort

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create role

Mon, 01 Jan 0001 00:00:00 +0000

简介

创建单一规则的角色。

kubectl create role NAME --verb=verb --resource=resource.group/subresource [--resource-name=resourcename] [--dry-run=server|client|none]

示例

# 创建一个名为 "pod-reader" 的角色，允许用户对 Pod 执行 "get"、"watch" 和 "list" 操作
kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods

# 创建一个名为 "pod-reader" 的角色，并指定资源名称
kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

# 创建一个名为 "foo" 的角色，并指定 API 组
kubectl create role foo --verb=get,list,watch --resource=rs.apps

# 创建一个名为 "foo" 的角色，并指定子资源
kubectl create role foo --verb=get,list,watch --resource=pods,pods/status

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create rolebinding

Mon, 01 Jan 0001 00:00:00 +0000

简介

为特定角色或集群角色创建角色绑定。

kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=用户名] [--group=组名] [--serviceaccount=命名空间:服务账户名] [--dry-run=server|client|none]

示例

# 使用 admin 集群角色为 user1、user2 和 group1 创建角色绑定
kubectl create rolebinding admin --clusterrole=admin --user=user1 --user=user2 --group=group1
 
# 使用 admin 角色为服务账户 monitoring:sa-dev 创建角色绑定
kubectl create rolebinding admin-binding --role=admin --serviceaccount=monitoring:sa-dev

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create secret

Mon, 01 Jan 0001 00:00:00 +0000

简介

创建指定类型的 Secret：

docker-registry 类型 Secret 用于访问容器镜像仓库。
generic 类型 Secret 表示不透明 Secret 类型。
tls 类型 Secret 包含 TLS 证书及其关联密钥。

kubectl create secret (docker-registry | generic | tls)

选项

-h, --help

secret 操作的帮助命令。

kubectl create secret docker-registry

Mon, 01 Jan 0001 00:00:00 +0000

简介

新建一个 Docker 仓库所用的 Secret。

Dockercfg Secret 用于向 Docker 仓库进行身份认证。

当使用 Docker 命令行推送镜像时，你可以通过运行以下命令向给定的仓库进行身份认证：

kubectl create secret generic

Mon, 01 Jan 0001 00:00:00 +0000

简介

基于文件、目录或指定的文字值创建 Secret。

单个 Secret 可以包含一个或多个键值对。

当基于文件创建 Secret 时，键将默认为文件的基本名称，值将默认为文件内容。如果基本名称是无效的键，或者你希望选择自己的键，你可以指定一个替代键。

kubectl create secret tls

Mon, 01 Jan 0001 00:00:00 +0000

简介

使用给定的公钥/私钥对创建 TLS Secret。

事先公钥/私钥对必须存在。公钥证书必须是以 .PEM 编码的，并且与给定的私钥匹配。

kubectl create secret tls NAME --cert=path/to/cert/file --key=path/to/key/file [--dry-run=server|client|none]

示例

# 使用给定的密钥对新建一个名为 tls-secret 的 TLS Secret
kubectl create secret tls tls-secret --cert=path/to/tls.crt --key=path/to/tls.key

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create service

Mon, 01 Jan 0001 00:00:00 +0000

简介

使用指定的子命令创建 Service。

kubectl create service [flags]

选项

-h, --help
	service 操作的帮助命令。

继承于父命令的选项

--as string

操作所用的伪装用户名。用户可以是常规用户或命名空间中的服务账号。

kubectl create service clusterip

Mon, 01 Jan 0001 00:00:00 +0000

简介

创建指定名称的 ClusterIP Service。

kubectl create service clusterip NAME [--tcp=<port>:<targetPort>] [--dry-run=server|client|none]

示例

# 新建一个名为 my-cs 的 ClusterIP Service
kubectl create service clusterip my-cs --tcp=5678:8080
 
# 新建一个名为 my-cs 的 ClusterIP Service（无头模式）
kubectl create service clusterip my-cs --clusterip="None"

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create service externalname

Mon, 01 Jan 0001 00:00:00 +0000

简介

创建指定名称的 ExternalName Service。

ExternalName Service 引用外部 DNS 地址，而不仅仅是 Pod，这类 Service 允许应用作者引用平台外、其他集群或本地存在的服务。

kubectl create service externalname NAME --external-name external.name [--dry-run=server|client|none]

示例

# 新建一个名为 my-ns 的 ExternalName Service
kubectl create service externalname my-ns --external-name bar.com

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create service loadbalancer

Mon, 01 Jan 0001 00:00:00 +0000

简介

创建指定名称的 LoadBalancer 类型 Service。

kubectl create service loadbalancer NAME [--tcp=port:targetPort] [--dry-run=server|client|none]

示例

# 新建名为 my-lbs 的 LoadBalancer 类型 Service
kubectl create service loadbalancer my-lbs --tcp=5678:8080

选项

--allow-missing-template-keys Default: true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create service nodeport

Mon, 01 Jan 0001 00:00:00 +0000

简介

创建一个指定名称的 NodePort 类型 Service。

kubectl create service nodeport NAME [--tcp=port:targetPort] [--dry-run=server|client|none]

示例

# 新建一个名为 my-ns 的 NodePort 类型 Service
kubectl create service nodeport my-ns --tcp=5678:8080

选项

--allow-missing-template-keys Default: true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create serviceaccount

Mon, 01 Jan 0001 00:00:00 +0000

简介

创建指定名称的服务账号。

kubectl create serviceaccount NAME [--dry-run=server|client|none]

示例

# 创建一个名为 my-service-account 的服务帐号
kubectl create serviceaccount my-service-account

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl create token

Mon, 01 Jan 0001 00:00:00 +0000

简介

请求一个服务账号令牌。

kubectl create token SERVICE_ACCOUNT_NAME

示例

# 请求一个令牌，以当前命名空间中的服务账号 "myapp" 向 kube-apiserver 进行身份认证
kubectl create token myapp
 
# 为特定命名空间中的服务账号请求一个令牌
kubectl create token myapp --namespace myns
 
# 请求一个含自定义过期时间的令牌
kubectl create token myapp --duration 10m
 
# 请求一个包含特定受众的令牌
kubectl create token myapp --audience https://example.com
 
# 请求一个绑定到 Secret 对象实例的令牌
kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret
 
# 请求一个绑定到特定 UID 的 Secret 对象实例的令牌
kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret --bound-object-uid 0d4691ed-659b-4935-a832-355f77ee47cc

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl plugin list

Mon, 01 Jan 0001 00:00:00 +0000

简介

列出用户 PATH 中所有可用的插件文件。

可用的插件文件需符合以下条件：

可执行文件
位于用户的 PATH 中某处
以 "kubectl-" 开头

kubectl plugin list [flags]

示例

# 列出所有可用的插件
kubectl plugin list

# 仅列出可用插件的二进制名称，不包含路径
kubectl plugin list --name-only

选项

-h, --help

list 命令的帮助信息。

kubectl rollout history

Mon, 01 Jan 0001 00:00:00 +0000

简介

查看以前上线的修订版本和配置。

kubectl rollout history (TYPE NAME | TYPE/NAME) [flags]

示例

# 查看 Deployment 的上线历史记录
kubectl rollout history deployment/abc
 
# 查看 DaemonSet 修订版本 3 的详细信息
kubectl rollout history daemonset/abc --revision=3

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl rollout pause

Mon, 01 Jan 0001 00:00:00 +0000

简介

将所提供的资源标记为已暂停。

控制器不会调和已暂停的资源。使用 kubectl rollout resume 可恢复已暂停的资源，目前只有 Deployment 支持暂停。

kubectl rollout pause RESOURCE

示例

# 将 nginx Deployment 标记为暂停
# Deployment 的任何当前状态都将继续发挥作用；
# 只要 Deployment 处于暂停状态，对 Deployment 的更新就不会产生影响
kubectl rollout pause deployment/nginx

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl rollout restart

Mon, 01 Jan 0001 00:00:00 +0000

简介

重启资源。

资源将重新开始上线。

kubectl rollout restart RESOURCE

示例

# 重启 test-namespace 命名空间下的所有 Deployment
kubectl rollout restart deployment -n test-namespace
 
# 重启 Deployment
kubectl rollout restart deployment/nginx
 
# 重启 DaemonSet
kubectl rollout restart daemonset/abc
 
# 重启带有标签 app=nginx 的 Deployment
kubectl rollout restart deployment --selector=app=nginx

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl rollout resume

Mon, 01 Jan 0001 00:00:00 +0000

简介

恢复暂停的资源。

控制器不会调和已暂停的资源。通过恢复资源，我们可以让控制器再次调和它，目前只有 Deployment 支持恢复。

kubectl rollout resume RESOURCE

示例

# 恢复已暂停的 Deployment
kubectl rollout resume deployment/nginx

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl rollout status

Mon, 01 Jan 0001 00:00:00 +0000

简介

显示上线的状态。

kubectl rollout undo

Mon, 01 Jan 0001 00:00:00 +0000

简介

回滚到之前上线的版本。

kubectl rollout undo (TYPE NAME | TYPE/NAME) [flags]

示例

# 回滚到上一个 Deployment 的上一次部署状态
kubectl rollout undo deployment/abc
 
# 回滚到 DaemonSet 的修订版本 3
kubectl rollout undo daemonset/abc --to-revision=3
 
# 试运行回滚到 Deployment 的上一次部署状态
kubectl rollout undo --dry-run=server deployment/abc

选项

--allow-missing-template-keys 默认值：true

如果为 true，在模板中字段或映射键缺失时忽略模板中的错误。仅适用于 golang 和 jsonpath 输出格式。

kubectl set env

Mon, 01 Jan 0001 00:00:00 +0000

简介

更新 Pod 模板中的环境变量。

kubectl set image

Mon, 01 Jan 0001 00:00:00 +0000

简介

更新资源的现有容器镜像。

可能的资源包括（不区分大小写）：

pod (po), replicationcontroller (rc), deployment (deploy), daemonset (ds), statefulset (sts), cronjob (cj), replicaset (rs)

kubectl set image (-f FILENAME | TYPE NAME) CONTAINER_NAME_1=CONTAINER_IMAGE_1 ... CONTAINER_NAME_N=CONTAINER_IMAGE_N

示例

# 将 Deployment 的 nginx 容器镜像设置为 “nginx:1.9.1”，并将其 busybox 容器镜像设置为 “busybox”
kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1

# 更新所有 Deployment 和副本控制器的 nginx 容器镜像为 “nginx:1.9.1”
kubectl set image deployments,rc nginx=nginx:1.9.1 --all
 
# 更新 DaemonSet abc 的所有容器镜像为 "nginx:1.9.1"
kubectl set image daemonset abc *=nginx:1.9.1
 
# 使用本地文件更新 nginx 容器镜像，并以 YAML 格式打印结果，但不向服务器发出请求
kubectl set image -f path/to/file.yaml nginx=nginx:1.9.1 --local -o yaml

选项

--all

在指定资源类型的命名空间中，选择所有资源。

kubectl set resources

Mon, 01 Jan 0001 00:00:00 +0000

简介

为定义 Pod 模板的任一资源指定计算资源要求（CPU、内存）。如果 Pod 被成功调度，将保证获得所请求的资源量，但可以在某一瞬间达到其指定的限制值。

kubectl set selector

Mon, 01 Jan 0001 00:00:00 +0000

简介

为某个资源设置选择算符。请注意，如果资源在 set selector 调用之前已有选择算符，则新的选择算符将覆盖旧的选择算符。

kubectl set serviceaccount

Mon, 01 Jan 0001 00:00:00 +0000

简介

更新 Pod 模板资源的服务账号。

可能的资源（不区分大小写）可以是：

replicationcontroller (rc), deployment (deploy), daemonset (ds), job, replicaset (rs), statefulset

kubectl set serviceaccount (-f FILENAME | TYPE NAME) SERVICE_ACCOUNT

示例

# 将名为 nginx-deployment 的 Deployment 的服务账号设置为 serviceaccount1
kubectl set serviceaccount deployment nginx-deployment serviceaccount1

# 打印使用本地文件中服务账号更新 nginx Deployment 后的结果（以 YAML 格式），不向 API 服务器发送请求
kubectl set sa -f nginx-deployment.yaml serviceaccount1 --local --dry-run=client -o yaml

选项

--all

在指定资源类型的命名空间中，选择所有资源。

kubectl set subject

Mon, 01 Jan 0001 00:00:00 +0000

简介

更新角色绑定或集群角色绑定中的用户、组或服务账号。

kubectl set subject (-f FILENAME | TYPE NAME) [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]

示例

# 更新 serviceaccount1 的集群角色绑定
kubectl set subject clusterrolebinding admin --serviceaccount=namespace:serviceaccount1
 
# 更新 user1、user2 和 group1 的角色绑定
kubectl set subject rolebinding admin --user=user1 --user=user2 --group=group1
 
# 打印从本地更新角色绑定主体的结果（以 YAML 格式），但不向服务器发送请求
kubectl create rolebinding admin --role=admin --user=admin -o yaml --dry-run=client | kubectl set subject --local -f - --user=foo -o yaml

选项

--all

在指定资源类型的命名空间中，选择所有资源。

kubectl top node

Mon, 01 Jan 0001 00:00:00 +0000

简介

显示节点的资源（CPU/内存）使用情况。

top-node 命令可以让你查看节点的资源消耗情况。

kubectl top node [NAME | -l label]

示例

# 显示所有节点的指标
kubectl top node
 
# 显示某个指定节点的指标
kubectl top node NODE_NAME

选项

-h, --help

node 操作的帮助命令。

kubectl top pod

Mon, 01 Jan 0001 00:00:00 +0000

简介

显示 Pod 的资源（CPU/内存）使用情况。

top pod 命令允许你查看 Pod 的资源消耗情况。

由于指标管道的延迟，Pod 创建后的几分钟内可能无法获取资源消耗数据。

kubectl top pod [NAME | -l label]

示例

# 显示 default 命名空间中所有 Pod 的指标
kubectl top pod

# 显示指定命名空间中所有 Pod 的指标
kubectl top pod --namespace=NAMESPACE

# 显示指定 Pod 及其容器的指标
kubectl top pod POD_NAME --containers

# 显示由标签 name=myLabel 所定义的 Pod 的指标
kubectl top pod -l name=myLabel

选项

-A, --all-namespaces

如果存在，则列举所有命名空间中请求的对象。即使使用 --namespace 指定，当前上下文中的命名空间也会被忽略。

Operator 模式

Mon, 01 Jan 0001 00:00:00 +0000

Operator 是 Kubernetes 的扩展软件，它利用定制资源管理应用及其组件。 Operator 遵循 Kubernetes 的理念，特别是在控制器方面。

初衷

Operator 模式旨在记述（正在管理一个或一组服务的）运维人员的关键目标。这些运维人员负责一些特定的应用和 Service，他们需要清楚地知道系统应该如何运行、如何部署以及出现问题时如何处理。

Pinterest Case Study

Mon, 01 Jan 0001 00:00:00 +0000

Challenge

After eight years in existence, Pinterest had grown into 1,000 microservices and multiple layers of infrastructure and diverse set-up tools and platforms. In 2016 the company launched a roadmap towards a new compute platform, led by the vision of creating the fastest path from an idea to production, without making engineers worry about the underlying infrastructure.

Solution

The first phase involved moving services to Docker containers. Once these services went into production in early 2017, the team began looking at orchestration to help create efficiencies and manage them in a decentralized way. After an evaluation of various solutions, Pinterest went with Kubernetes.

Pod 安全策略

Mon, 01 Jan 0001 00:00:00 +0000

被移除的特性

PodSecurityPolicy 在 Kubernetes v1.21 中被弃用，在 Kubernetes v1.25 中被移除。

作为替代，你可以使用下面任一方式执行类似的限制，或者同时使用下面这两种方式。

Pod 安全准入
自行部署并配置第三方准入插件

有关如何迁移，参阅从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器。有关移除此 API 的更多信息，参阅弃用 PodSecurityPolicy：过去、现在、未来。

Pod 的生命周期

Mon, 01 Jan 0001 00:00:00 +0000

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

Pod 开销

Mon, 01 Jan 0001 00:00:00 +0000

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

在节点上运行 Pod 时，Pod 本身占用大量系统资源。这些是运行 Pod 内容器所需资源之外的资源。在 Kubernetes 中，POD 开销 是一种方法，用于计算 Pod 基础设施在容器请求和限制之上消耗的资源。

Secret

Mon, 01 Jan 0001 00:00:00 +0000

Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。这样的信息可能会被放在 Pod 规约中或者镜像中。使用 Secret 意味着你不需要在应用程序代码中包含机密数据。

StatefulSet

Mon, 01 Jan 0001 00:00:00 +0000

StatefulSet 是用来管理有状态应用的工作负载 API 对象。

提交案例分析

Mon, 01 Jan 0001 00:00:00 +0000

案例分析用来概述组织如何使用 Kubernetes 解决现实世界的问题。 Kubernetes 市场化团队和 CNCF 成员会与你一起工作，撰写所有的案例分析。

查明节点上所使用的容器运行时

Mon, 01 Jan 0001 00:00:00 +0000

本页面描述查明集群中节点所使用的容器运行时的步骤。

取决于你运行集群的方式，节点所使用的容器运行时可能是事先配置好的，也可能需要你来配置。如果你在使用托管的 Kubernetes 服务，可能存在特定于厂商的方法来检查节点上配置的容器运行时。本页描述的方法应该在能够执行 kubectl 的场合下都可以工作。

带 Pod 间通信的 Job

Mon, 01 Jan 0001 00:00:00 +0000

在此例中，你将以索引完成模式运行一个 Job，并通过配置使得该 Job 所创建的各 Pod 之间可以使用 Pod 主机名而不是 Pod IP 地址进行通信。

调度策略

Mon, 01 Jan 0001 00:00:00 +0000

在 Kubernetes v1.23 版本之前，可以使用调度策略来指定 predicates 和 priorities 进程。例如，可以通过运行 kube-scheduler --policy-config-file <filename> 或者 kube-scheduler --policy-configmap <ConfigMap> 设置调度策略。

调试 StatefulSet

Mon, 01 Jan 0001 00:00:00 +0000

此任务展示如何调试 StatefulSet。

准备开始

你需要有一个 Kubernetes 集群，已配置好的 kubectl 命令行工具与你的集群进行通信。
你应该有一个运行中的 StatefulSet，以便用于调试。

调试 StatefulSet

StatefulSet 在创建 Pod 时为其设置了 app.kubernetes.io/name=MyApp 标签，列出仅属于某 StatefulSet 的所有 Pod 时，可以使用以下命令：

调整分配给容器的 CPU 和内存资源

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.35 [stable]（默认启用）

本页面说明了如何在不重新创建 Pod 的情况下，更改分配给容器的 CPU 和内存资源请求与限制。

传统上，更改 Pod 的资源需求需要删除现有 Pod 并创建一个替代 Pod，这通常由工作负载控制器管理。而就地 Pod 调整功能允许在运行中的 Pod 内变更容器的 CPU 和内存分配，从而可能避免干扰应用。 Pod 资源调整的流程详见：调整分配给 Pod 的 CPU 与内存资源。

对象名称和 ID

Mon, 01 Jan 0001 00:00:00 +0000

集群中的每一个对象都有一个名称来标识在同类资源中的唯一性。

分配 Pod 级别 CPU 和内存资源

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.34 [beta]（默认启用）

本页介绍除了容器级别的资源规约外，如何在 Pod 级别指定 CPU 和内存资源。 Kubernetes 节点基于 Pod 的资源请求分配资源。这些请求可以在 Pod 级别定义，也可以逐个为 Pod 内的容器定义。当两种级别的请求都存在时，Pod 级别的请求优先。

给 Kubernetes 博客提交文章

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 有两个官方博客，CNCF 也有自己的博客频道，你也可以在 CNCF 博客频道上发布与 Kubernetes 相关的内容。对于 Kubernetes 主博客，我们（Kubernetes 项目组）希望发布与 Kubernetes 有关联的具有不同视角和独特关注点的文章。

鉴权

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 鉴权在身份认证之后进行。通常，发出请求的客户端必须经过身份验证（登录）才能允许其请求；但是，Kubernetes 在某些情况下也允许匿名请求。

仅在某些节点上运行 Pod

Mon, 01 Jan 0001 00:00:00 +0000

本页演示了你如何能够仅在某些节点上作为 DaemonSet 的一部分运行Pod。

准备开始

客户端库

Mon, 01 Jan 0001 00:00:00 +0000

本页面概要介绍了基于各种编程语言使用 Kubernetes API 的客户端库。

在使用 Kubernetes REST API 编写应用程序时，你并不需要自己实现 API 调用和 “请求/响应” 类型。你可以根据自己的编程语言需要选择使用合适的客户端库。

控制器

Mon, 01 Jan 0001 00:00:00 +0000

在机器人技术和自动化领域，控制回路（Control Loop）是一个非终止回路，用于调节系统状态。

临时卷

Mon, 01 Jan 0001 00:00:00 +0000

本文档描述 Kubernetes 中的 临时卷（Ephemeral Volume）。建议先了解卷，特别是 PersistentVolumeClaim 和 PersistentVolume。

有些应用程序需要额外的存储，但并不关心数据在重启后是否仍然可用。例如，缓存服务经常受限于内存大小，而且可以将不常用的数据转移到比内存慢的存储中，对总体性能的影响并不大。

配置对多集群的访问

Mon, 01 Jan 0001 00:00:00 +0000

本文展示如何使用配置文件来配置对多个集群的访问。在将集群、用户和上下文定义在一个或多个配置文件中之后，用户可以使用 kubectl config use-context 命令快速地在集群之间进行切换。

配置命名空间的最小和最大内存约束

Mon, 01 Jan 0001 00:00:00 +0000

本页介绍如何设置在名字空间中运行的容器所使用的内存的最小值和最大值。你可以在 LimitRange 对象中指定最小和最大内存值。如果 Pod 不满足 LimitRange 施加的约束，则无法在名字空间中创建它。

确定 Pod 失败的原因

Mon, 01 Jan 0001 00:00:00 +0000

本文介绍如何编写和读取容器的终止消息。

终止消息为容器提供了一种方法，可以将有关致命事件的信息写入某个位置，在该位置可以通过仪表板和监控软件等工具轻松检索和显示致命事件。在大多数情况下，你放入终止消息中的信息也应该写入常规 Kubernetes 日志。

容器运行时类（Runtime Class）

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.20 [stable]

本页面描述了 RuntimeClass 资源和运行时的选择机制。

RuntimeClass 是一个用于选择容器运行时配置的特性，容器运行时配置用于运行 Pod 中的容器。

动机

你可以在不同的 Pod 设置不同的 RuntimeClass，以提供性能与安全性之间的平衡。例如，如果你的部分工作负载需要高级别的信息安全保证，你可以决定在调度这些 Pod 时尽量使它们在使用硬件虚拟化的容器运行时中运行。这样，你将从这些不同运行时所提供的额外隔离中获益，代价是一些额外的开销。

升级 kubeadm 集群

Mon, 01 Jan 0001 00:00:00 +0000

本页介绍如何将 kubeadm 创建的 Kubernetes 集群从 1.34.x 版本升级到 1.35.x 版本以及从 1.35.x 升级到 1.35.y（其中 y > x）。略过次版本号的升级是不被支持的。更多详情请访问版本偏差策略。

使用 AppArmor 限制容器对资源的访问

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.31 [stable]（默认启用）

本页面向你展示如何在节点上加载 AppArmor 配置文件并在 Pod 中强制应用这些配置文件。要了解有关 Kubernetes 如何使用 AppArmor 限制 Pod 的更多信息，请参阅 Pod 和容器的 Linux 内核安全约束。

使用 Cilium 提供 NetworkPolicy

Mon, 01 Jan 0001 00:00:00 +0000

本页展示如何使用 Cilium 提供 NetworkPolicy。

关于 Cilium 的背景知识，请阅读 Cilium 介绍。

准备开始

使用 ConfigMap 来配置 Redis

Mon, 01 Jan 0001 00:00:00 +0000

这篇文档基于配置 Pod 以使用 ConfigMap 这个任务，提供了一个使用 ConfigMap 来配置 Redis 的真实案例。

教程目标

使用 Redis 配置的值创建一个 ConfigMap
创建一个 Redis Pod，挂载并使用创建的 ConfigMap
验证配置已经被正确应用

准备开始

使用 crictl 对 Kubernetes 节点进行调试

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.11 [stable]

crictl 是 CRI 兼容的容器运行时命令行接口。你可以使用它来检查和调试 Kubernetes 节点上的容器运行时和应用程序。 crictl 和它的源代码在 cri-tools 代码库。

使用 Init 容器定义环境变量值

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.35 [beta]（默认启用）

本页展示如何通过文件为 Pod 中的容器配置环境变量。

准备开始

使用 kubeadm 创建集群

Mon, 01 Jan 0001 00:00:00 +0000

使用 kubeadm，你能创建一个符合最佳实践的最小化 Kubernetes 集群。事实上，你可以使用 kubeadm 配置一个通过 Kubernetes 一致性测试的集群。 kubeadm 还支持其他集群生命周期功能，例如启动引导令牌和集群升级。

使用 Kustomize 管理 Secret

Mon, 01 Jan 0001 00:00:00 +0000

kubectl 支持使用 Kustomize 对象管理工具来管理 Secret 和 ConfigMap。你可以使用 Kustomize 创建资源生成器（Resource Generator），该生成器会生成一个 Secret，让你能够通过 kubectl 应用到 API 服务器。

使用工作队列进行精细的并行处理

Mon, 01 Jan 0001 00:00:00 +0000

在此示例中，你将运行一个 Kubernetes Job，该 Job 将多个并行任务作为工作进程运行，每个任务在单独的 Pod 中运行。

在这个例子中，当每个 Pod 被创建时，它会从一个任务队列中获取一个工作单元，处理它，然后重复，直到到达队列的尾部。

使用索引作业完成静态工作分配下的并行处理

Mon, 01 Jan 0001 00:00:00 +0000

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

在此示例中，你将运行一个使用多个并行工作进程的 Kubernetes Job。每个 worker 都是在自己的 Pod 中运行的不同容器。 Pod 具有控制平面自动设置的索引编号（index number），这些编号使得每个 Pod 能识别出要处理整个任务的哪个部分。

使用指令式命令管理 Kubernetes 对象

Mon, 01 Jan 0001 00:00:00 +0000

使用构建在 kubectl 命令行工具中的指令式命令可以直接快速创建、更新和删除 Kubernetes 对象。本文档解释这些命令的组织方式以及如何使用它们来管理活跃对象。

准备开始

安装kubectl。

示例：使用 StatefulSet 部署 Cassandra

Mon, 01 Jan 0001 00:00:00 +0000

本教程描述了如何在 Kubernetes 上运行 Apache Cassandra。数据库 Cassandra 需要永久性存储提供数据持久性（应用状态）。在此示例中，自定义 Cassandra seed provider 使数据库在接入 Cassandra 集群时能够发现新的 Cassandra 实例。

手动生成证书

Mon, 01 Jan 0001 00:00:00 +0000

在使用客户端证书认证的场景下，你可以通过 easyrsa、 openssl 或 cfssl 等工具以手工方式生成证书。

easyrsa

easyrsa 支持以手工方式为你的集群生成证书。

下载、解压、初始化打过补丁的 easyrsa3。

curl -LO https://dl.k8s.io/easy-rsa/easy-rsa.tar.gz
tar xzf easy-rsa.tar.gz
cd easy-rsa-master/easyrsa3
./easyrsa init-pki

生成新的证书颁发机构（CA）。参数 --batch 用于设置自动模式；参数 --req-cn 用于设置新的根证书的通用名称（CN）。

通过环境变量将 Pod 信息呈现给容器

Mon, 01 Jan 0001 00:00:00 +0000

此页面展示 Pod 如何使用 downward API 通过环境变量把自身的信息呈现给 Pod 中运行的容器。你可以使用环境变量来呈现 Pod 的字段、容器字段或两者。

在 Kubernetes 中有两种方式可以将 Pod 和容器字段呈现给运行中的容器：

为 Windows Pod 和容器配置 GMSA

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.18 [stable]

本页展示如何为将运行在 Windows 节点上的 Pod 和容器配置组管理的服务账号（Group Managed Service Accounts，GMSA）。组管理的服务账号是活动目录（Active Directory）的一种特殊类型，提供自动化的密码管理、简化的服务主体名称（Service Principal Name，SPN）管理以及跨多个服务器将管理操作委派给其他管理员等能力。

校验节点设置

Mon, 01 Jan 0001 00:00:00 +0000

节点一致性测试

节点一致性测试是一个容器化的测试框架，提供了针对节点的系统验证和功能测试。测试验证节点是否满足 Kubernetes 的最低要求；通过测试的节点有资格加入 Kubernetes 集群。

运行一个有状态的应用程序

Mon, 01 Jan 0001 00:00:00 +0000

本页展示如何使用 StatefulSet 控制器运行一个有状态的应用程序。此例是多副本的 MySQL 数据库。示例应用的拓扑结构有一个主服务器和多个副本，使用异步的基于行（Row-Based）的数据复制。

租约（Lease）

Mon, 01 Jan 0001 00:00:00 +0000

分布式系统通常需要租约（Lease）；租约提供了一种机制来锁定共享资源并协调集合成员之间的活动。在 Kubernetes 中，租约概念表示为 coordination.k8s.io API 组中的 Lease 对象，常用于类似节点心跳和组件级领导者选举等系统核心能力。

使用 RBAC 鉴权

Mon, 01 Jan 0001 00:00:00 +0000

基于角色（Role）的访问控制（RBAC）是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法。

RBAC 鉴权机制使用 rbac.authorization.k8s.io API 组来驱动鉴权决定，允许你通过 Kubernetes API 动态配置策略。

使用 Node 鉴权

Mon, 01 Jan 0001 00:00:00 +0000

节点鉴权是一种特殊用途的鉴权模式，专门对 kubelet 发出的 API 请求进行授权。

概述

节点鉴权器允许 kubelet 执行 API 操作。包括：

读取操作：

Kubernetes 中的通用表达式语言

Mon, 01 Jan 0001 00:00:00 +0000

通用表达式语言 (Common Expression Language, CEL) 用于声明 Kubernetes API 的验证规则、策略规则和其他限制或条件。

在 Kubernetes 节点上配置交换内存

Mon, 01 Jan 0001 00:00:00 +0000

本文演示了如何使用 kubeadm 在 Kubernetes 节点上制备和启用交换内存。

教程目标

使用 kubeadm 在 Kubernetes 节点上制备交换内存。
学习配置加密和未加密的交换内存。
学习如何在系统启动时启用交换内存。

准备开始

Webhook 模式

Mon, 01 Jan 0001 00:00:00 +0000

Webhook 是一种 HTTP 回调：某些条件下触发的 HTTP POST 请求；通过 HTTP POST 发送的简单事件通知。一个基于 web 应用实现的 Webhook 会在特定事件发生时把消息发送给特定的 URL。

使用 ABAC 鉴权

Mon, 01 Jan 0001 00:00:00 +0000

基于属性的访问控制（Attribute-based access control，ABAC）定义了访问控制范例， ABAC 通过使用将属性组合在一起的策略来向用户授予访问权限。

策略文件格式

要启用 ABAC 模式，可以在启动时指定 --authorization-policy-file=SOME_FILENAME 和 --authorization-mode=ABAC。

DaemonSet

Mon, 01 Jan 0001 00:00:00 +0000

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，也会为他们新增一个 Pod 。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

Init 容器

Mon, 01 Jan 0001 00:00:00 +0000

本页提供了 Init 容器的概览。Init 容器是一种特殊容器，在 Pod 内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本。

你可以在 Pod 的规约中与用来描述应用容器的 containers 数组平行的位置指定 Init 容器。

JSONPath 支持

Mon, 01 Jan 0001 00:00:00 +0000

kubectl 工具支持 JSONPath 模板作为输出格式。

JSONPath 模板由大括号 { 和 } 包起来的 JSONPath 表达式组成。 kubectl 使用 JSONPath 表达式来过滤 JSON 对象中的特定字段并格式化输出。除了原始的 JSONPath 模板语法，以下函数和语法也是有效的:

kubeadm upgrade

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm upgrade 是一个对用户友好的命令，它将复杂的升级逻辑包装在一条命令后面，支持升级的规划和实际执行。

kubeadm upgrade 指南

本文档概述使用 kubeadm 执行升级的步骤。与 kubeadm 旧版本相关的文档，请参阅 Kubernetes 网站的旧版文档。

kubeadm upgrade phases

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm upgrade apply 阶段

使用 kubeadm upgrade apply 的各个阶段，你可以选择执行控制平面节点初始升级的单独步骤。

概要

使用此命令来调用 "apply" 工作流的单个阶段。

Kubernetes API

Mon, 01 Jan 0001 00:00:00 +0000

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

Kubernetes 弃用策略

Mon, 01 Jan 0001 00:00:00 +0000

本文档详细解释系统中各个层面的弃用策略（Deprecation Policy）。

Kubernetes 是一个组件众多、贡献者人数众多的大系统。就像很多类似的软件，所提供的功能特性集合会随着时间推移而自然发生变化，而且有时候某个功能特性可能需要被移除。被移除的可能是一个 API、一个参数标志或者甚至某整个功能特性。为了避免影响到现有用户， Kubernetes 对于其中渐次移除的各个方面规定了一种弃用策略并遵从此策略。

Linux 节点的安全性

Mon, 01 Jan 0001 00:00:00 +0000

本篇介绍特定于 Linux 操作系统的安全注意事项和最佳实践。

保护节点上的 Secret 数据

在 Linux 节点上，由内存支持的卷（例如 secret 卷挂载，或带有 medium: Memory 的 emptyDir）使用 tmpfs 文件系统实现。

Pod 调度就绪态

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.30 [stable]

Pod 一旦创建就被认为准备好进行调度。 Kubernetes 调度程序尽职尽责地寻找节点来放置所有待处理的 Pod。然而，在实际环境中，会有一些 Pod 可能会长时间处于"缺少必要资源"状态。这些 Pod 实际上以一种不必要的方式扰乱了调度器（以及 Cluster AutoScaler 这类下游的集成方）。

Pod 拓扑分布约束

Mon, 01 Jan 0001 00:00:00 +0000

你可以使用 拓扑分布约束（Topology Spread Constraints） 来控制 Pod 在集群内故障域之间的分布，例如区域（Region）、可用区（Zone）、节点和其他用户自定义拓扑域。这样做有助于实现高可用并提升资源利用率。

Turnkey 云解决方案

Mon, 01 Jan 0001 00:00:00 +0000

本页列示 Kubernetes 认证解决方案供应商。在每一个供应商分页，你可以学习如何安装和设置生产就绪的集群。

Windows 节点的安全性

Mon, 01 Jan 0001 00:00:00 +0000

本篇介绍特定于 Windows 操作系统的安全注意事项和最佳实践。

保护节点上的 Secret 数据

在 Windows 上，来自 Secret 的数据以明文形式写入节点的本地存储（与在 Linux 上使用 tmpfs / 内存中文件系统不同）。作为集群操作员，你应该采取以下两项额外措施：

标签和选择算符

Mon, 01 Jan 0001 00:00:00 +0000

标签（Labels） 是附加到 Kubernetes 对象（比如 Pod）上的键值对。标签旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。标签可以用于组织和选择对象的子集。标签可以在创建时附加到对象，随后可以随时添加和修改。每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的。

博客指南

Mon, 01 Jan 0001 00:00:00 +0000

这些指南涵盖了 Kubernetes 主博客和 Kubernetes 贡献者博客。

所有博客内容还必须遵循内容指南中的总体政策。

准备开始

确保你熟悉为 Kubernetes 博客贡献内容的介绍部分，不仅是为了了解两个官方博客及其之间的区别，也是为了对整个过程有一个概览。

存储类

Mon, 01 Jan 0001 00:00:00 +0000

本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉卷和持久卷的概念。

StorageClass 为管理员提供了描述存储类的方法。不同的类型可能会映射到不同的服务质量等级或备份策略，或是由集群管理员制定的任意策略。 Kubernetes 本身并不清楚各种类代表的什么。

存活、就绪和启动探针

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 提供了多种探针：

存活探针
就绪探针
启动探针

存活探针

存活探针决定何时重启容器。例如，当应用在运行但无法取得进展时，存活探针可以捕获这类死锁。

调试 Init 容器

Mon, 01 Jan 0001 00:00:00 +0000

此页显示如何核查与 Init 容器执行相关的问题。下面的示例命令行将 Pod 称为 <pod-name>，而 Init 容器称为 <init-container-1> 和 <init-container-2>。

管理工作负载

Mon, 01 Jan 0001 00:00:00 +0000

你已经部署了你的应用并且通过 Service 将其暴露出来。现在要做什么？ Kubernetes 提供了一系列的工具帮助你管理应用的部署，包括扩缩和更新。

组织资源配置

一些应用需要创建多个资源，例如 Deployment 和 Service。将多个资源归入同一个文件（在 YAML 中使用 --- 分隔）可以简化对多个资源的管理。例如：

进程 ID 约束与预留

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.20 [stable]

Kubernetes 允许你限制一个 Pod 中可以使用的进程 ID（PID）数目。你也可以为每个节点预留一定数量的可分配的 PID，供操作系统和守护进程（而非 Pod）使用。

卷属性类

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.34 [stable]（默认启用）

本页假设你已经熟悉 Kubernetes 中的 StorageClass、 Volume 和 PersistentVolume。

卷属性类（VolumeAttributesClass）为管理员提供了一种描述可变更的存储“类”的方法。不同的类可以映射到不同的服务质量级别。Kubernetes 本身不关注这些类代表什么。

排查 CNI 插件相关的错误

Mon, 01 Jan 0001 00:00:00 +0000

为了避免 CNI 插件相关的错误，需要验证你正在使用或升级到的容器运行时经过测试能够在你的 Kubernetes 版本上正常工作。

关于 "Incompatible CNI versions" 和 "Failed to destroy network for sandbox" 错误

在 containerd v1.6.0 到 v1.6.3 中，当配置或清除 Pod CNI 网络时，如果 CNI 插件没有升级和/或 CNI 配置文件中没有声明 CNI 配置版本，会出现服务问题。containerd 团队报告说： “这些问题在 containerd v1.6.4 中得到了解决。”

强制实施 Pod 安全性标准

Mon, 01 Jan 0001 00:00:00 +0000

本页提供实施 Pod 安全标准（Pod Security Standards）时的一些最佳实践。

使用内置的 Pod 安全性准入控制器

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

Pod 安全性准入控制器尝试替换已被废弃的 PodSecurityPolicies。

容器生命周期回调

Mon, 01 Jan 0001 00:00:00 +0000

这个页面描述了 kubelet 管理的容器如何使用容器生命周期回调框架，藉由其管理生命周期中的事件触发，运行指定代码。

概述

类似于许多具有生命周期回调组件的编程语言框架，例如 Angular、Kubernetes 为容器提供了生命周期回调。回调使容器能够了解其管理生命周期中的事件，并在执行相应的生命周期回调时运行在处理程序中实现的代码。

升级 Linux 节点

Mon, 01 Jan 0001 00:00:00 +0000

本页讲述了如何升级用 kubeadm 创建的 Linux 工作节点。

准备开始

你必须有 Shell 能访问所有节点，且必须配置 kubectl 命令行工具让其与你的集群通信。建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。

使用 HTTP 代理访问 Kubernetes API

Mon, 01 Jan 0001 00:00:00 +0000

本文说明如何使用 HTTP 代理访问 Kubernetes API。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

使用 kube-router 提供 NetworkPolicy

Mon, 01 Jan 0001 00:00:00 +0000

本页展示如何使用 Kube-router 提供 NetworkPolicy。

准备开始

你需要拥有一个运行中的 Kubernetes 集群。如果你还没有集群，可以使用任意的集群安装程序如 Kops、Bootkube、Kubeadm 等创建一个。

使用 kubeadm API 定制组件

Mon, 01 Jan 0001 00:00:00 +0000

本页面介绍了如何自定义 kubeadm 部署的组件。你可以使用 ClusterConfiguration 结构中定义的参数，或者在每个节点上应用补丁来定制控制平面组件。你可以使用 KubeletConfiguration 和 KubeProxyConfiguration 结构分别定制 kubelet 和 kube-proxy 组件。

使用 seccomp 限制容器的系统调用

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.19 [stable]

Seccomp 代表安全计算（Secure Computing）模式，自 2.6.12 版本以来，一直是 Linux 内核的一个特性。它可以用来沙箱化进程的权限，限制进程从用户态到内核态的调用。 Kubernetes 能使你自动将加载到节点上的 seccomp 配置文件应用到你的 Pod 和容器。

使用边车（Sidecar）容器

Mon, 01 Jan 0001 00:00:00 +0000

本文适用于使用新的内置边车容器特性的用户。

使用端口转发来访问集群中的应用

Mon, 01 Jan 0001 00:00:00 +0000

本文展示如何使用 kubectl port-forward 连接到在 Kubernetes 集群中运行的 MongoDB 服务。这种类型的连接对数据库调试很有用。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

使用配置文件对 Kubernetes 对象进行命令式管理

Mon, 01 Jan 0001 00:00:00 +0000

可以使用 kubectl 命令行工具以及用 YAML 或 JSON 编写的对象配置文件来创建、更新和删除 Kubernetes 对象。本文档说明了如何使用配置文件定义和管理对象。

准备开始

安装 kubectl。

使用源 IP

Mon, 01 Jan 0001 00:00:00 +0000

运行在 Kubernetes 集群中的应用程序通过 Service 抽象发现彼此并相互通信，它们也用 Service 与外部世界通信。本文解释了发送到不同类型 Service 的数据包的源 IP 会发生什么情况，以及如何根据需要切换此行为。

通过文件将 Pod 信息呈现给容器

Mon, 01 Jan 0001 00:00:00 +0000

此页面描述 Pod 如何使用 downwardAPI 卷把自己的信息呈现给 Pod 中运行的容器。 downwardAPI 卷可以呈现 Pod 和容器的字段。

在 Kubernetes 中，有两种方式可以将 Pod 和容器字段呈现给运行中的容器：

为 Pod 和容器管理资源

Mon, 01 Jan 0001 00:00:00 +0000

当你定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。最常见的可设定资源是 CPU 和内存（RAM）大小；此外还有其他类型的资源。

为 Windows 的 Pod 和容器配置 RunAsUserName

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.18 [stable]

本页展示如何为运行为在 Windows 节点上运行的 Pod 和容器配置 RunAsUserName。大致相当于 Linux 上的 runAsUser，允许在容器中以与默认值不同的用户名运行应用。

为命名空间配置 CPU 最小和最大约束

Mon, 01 Jan 0001 00:00:00 +0000

本页介绍如何为命名空间中的容器和 Pod 设置其所使用的 CPU 资源的最小和最大值。你可以通过 LimitRange 对象声明 CPU 的最小和最大值. 如果 Pod 不能满足 LimitRange 的限制，就无法在该命名空间中被创建。

文档样式指南

Mon, 01 Jan 0001 00:00:00 +0000

本页讨论 Kubernetes 文档的样式指南。这些仅仅是指南而不是规则。你可以自行决定，且欢迎使用 PR 来为此文档提供修改意见。

由 kubelet 填充的节点标签

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 节点预先填充了一组标准标签。

你还可以通过 kubelet 配置或使用 Kubernetes API 在节点上设置自己的标签。

预设标签

Kubernetes 在节点上设置的预设标签有：

云控制器管理器

Mon, 01 Jan 0001 00:00:00 +0000

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

使用云基础设施技术，你可以在公有云、私有云或者混合云环境中运行 Kubernetes。 Kubernetes 的信条是基于自动化的、API 驱动的基础设施，同时避免组件间紧密耦合。

组件 cloud-controller-manager 是指云控制器管理器，一个 Kubernetes 控制平面组件，嵌入了特定于云平台的控制逻辑。云控制器管理器（Cloud Controller Manager）允许将你的集群连接到云提供商的 API 之上，并将与该云平台交互的组件同与你的集群交互的组件分离开来。

运行 ZooKeeper，一个分布式协调系统

Mon, 01 Jan 0001 00:00:00 +0000

本教程展示了在 Kubernetes 上使用 StatefulSet、 PodDisruptionBudget 和 PodAntiAffinity 特性运行 Apache Zookeeper。

准备开始

在开始本教程前，你应该熟悉以下 Kubernetes 概念。

Kubernetes 中的准入控制

Mon, 01 Jan 0001 00:00:00 +0000

此页面提供准入控制器（Admission Controller） 的概述。

准入控制器是一段代码，它会在请求通过认证和鉴权之后、对象被持久化之前拦截到达 API 服务器的请求。

升级 Windows 节点

Mon, 01 Jan 0001 00:00:00 +0000

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

本页解释如何升级用 kubeadm 创建的 Windows 节点。

准备开始

kubelet 所使用的本地文件和路径

Mon, 01 Jan 0001 00:00:00 +0000

kubelet 是一个运行在 Kubernetes 节点上的无状态进程。本文简要介绍了 kubelet 读写的文件。

说明：

本文仅供参考，而非描述保证会发生的行为或 API。本文档列举 kubelet 所使用的资源。所给的信息属于实现细节，可能会在后续版本中发生变更。

使用 SOCKS5 代理访问 Kubernetes API

Mon, 01 Jan 0001 00:00:00 +0000

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

本文展示了如何使用 SOCKS5 代理访问远程 Kubernetes 集群的 API。当你要访问的集群不直接在公共 Internet 上公开其 API 时，这很有用。

准备开始

动态准入控制

Mon, 01 Jan 0001 00:00:00 +0000

除了内置的 admission 插件，准入插件可以作为扩展独立开发，并以运行时所配置的 Webhook 的形式运行。此页面描述了如何构建、配置、使用和监视准入 Webhook。

什么是准入 Webhook？

准入 Webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。可以定义两种类型的准入 Webhook，即验证性质的准入 Webhook 和变更性质的准入 Webhook。变更性质的准入 Webhook 会先被调用。它们可以修改发送到 API 服务器的对象以执行自定义的设置默认值操作。

名字空间

Mon, 01 Jan 0001 00:00:00 +0000

在 Kubernetes 中，名字空间（Namespace） 提供一种机制，将同一集群中的资源划分为相互隔离的组。同一名字空间内的资源名称要唯一，但跨名字空间时没有这个要求。名字空间作用域仅针对带有名字空间的对象，（例如 Deployment、Service 等），这种作用域对集群范围的对象（例如 StorageClass、Node、PersistentVolume 等）不适用。

已弃用 API 的迁移指南

Mon, 01 Jan 0001 00:00:00 +0000

随着 Kubernetes API 的演化，API 会周期性地被重组或升级。当 API 演化时，老的 API 会被弃用并被最终删除。本页面包含你在将已弃用 API 版本迁移到新的更稳定的 API 版本时需要了解的知识。

Adform Case Study

Mon, 01 Jan 0001 00:00:00 +0000

CASE STUDY:

Improving Performance and Morale with Cloud Native

Company AdForm Location Copenhagen, Denmark Industry Adtech

Challenge

Adform’s mission is to provide a secure and transparent full stack of advertising technology to enable digital ads across devices. The company has a large infrastructure: OpenStack-based private clouds running on 1,100 physical servers in 7 data centers around the world, 3 of which were opened in the past year. With the company’s growth, the infrastructure team felt that "our private cloud was not really flexible enough," says IT System Engineer Edgaras Apšega. "The biggest pain point is that our developers need to maintain their virtual machines, so rolling out technology and new software takes time. We were really struggling with our releases, and we didn’t have self-healing infrastructure."

Solution

The team, which had already been using Prometheus for monitoring, embraced Kubernetes and cloud native practices in 2017. "To start our Kubernetes journey, we had to adapt all our software, so we had to choose newer frameworks," says Apšega. "We also adopted the microservices way, so observability is much better because you can inspect the bug or the services separately."

Impact

"Kubernetes helps our business a lot because our features are coming to market faster," says Apšega. The release process went from several hours to several minutes. Autoscaling has been at least 6 times faster than the semi-manual VM bootstrapping and application deployment required before. The team estimates that the company has experienced cost savings of 4-5x due to less hardware and fewer man hours needed to set up the hardware and virtual machines, metrics, and logging. Utilization of the hardware resources has been reduced as well, with containers notching 2-3 times more efficiency over virtual machines. "The deployments are very easy because developers just push the code and it automatically appears on Kubernetes," says Apšega. Prometheus has also had a positive impact: "It provides high availability for metrics and alerting. We monitor everything starting from hardware to applications. Having all the metrics in Grafana dashboards provides great insight on your systems."

"Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier."

— Edgaras Apšega, IT Systems Engineer, Adform

Adform made headlines last year when it detected the HyphBot ad fraud network that was costing some businesses hundreds of thousands of dollars a day.

With its mission to provide a secure and transparent full stack of advertising technology to enable an open internet, Adform published a white paper revealing what it did—and others could too—to limit customers’ exposure to the scam.

In that same spirit, Adform is sharing its cloud native journey. "When you see that everyone shares their best practices, it inspires you to contribute back to the project," says IT Systems Engineer Edgaras Apšega.

The company has a large infrastructure: OpenStack-based private clouds running on 1,100 physical servers in their own seven data centers around the world, three of which were opened in the past year. With the company’s growth, the infrastructure team felt that "our private cloud was not really flexible enough," says Apšega. "The biggest pain point is that our developers need to maintain their virtual machines, so rolling out technology and new software really takes time. We were really struggling with our releases, and we didn’t have self-healing infrastructure."

"The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral. And we can see that a community really gathers around it. Everyone shares their experiences, their knowledge, and the fact that it’s open source, you can contribute."

— Edgaras Apšega, IT Systems Engineer, Adform

The team, which had already been using Prometheus for monitoring, embraced Kubernetes, microservices, and cloud native practices. "The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral," says Apšega. "And we can see that a community really gathers around it."

A proof of concept project was started, with a Kubernetes cluster running on bare metal in the data center. When developers saw how quickly containers could be spun up compared to the virtual machine process, "they wanted to ship their containers in production right away, and we were still doing proof of concept," says IT Systems Engineer Andrius Cibulskis. Of course, a lot of work still had to be done. "First of all, we had to learn Kubernetes, see all of the moving parts, how they glue together," says Apšega. "Second of all, the whole CI/CD part had to be redone, and our DevOps team had to invest more man hours to implement it. And third is that developers had to rewrite the code, and they’re still doing it."

The first production cluster was launched in the spring of 2018, and is now up to 20 physical machines dedicated for pods throughout three data centers, with plans for separate clusters in the other four data centers. The user-facing Adform application platform, data distribution platform, and back ends are now all running on Kubernetes. "Many APIs for critical applications are being developed for Kubernetes," says Apšega. "Teams are rewriting their applications to .NET core, because it supports containers, and preparing to move to Kubernetes. And new applications, by default, go in containers."

"Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore."

— Andrius Cibulskis, IT Systems Engineer, Adform

This big push has been driven by the real impact that these new practices have had. "Kubernetes helps our business a lot because our features are coming to market faster," says Apšega. "The deployments are very easy because developers just push the code and it automatically appears on Kubernetes." The release process went from several hours to several minutes. Autoscaling is at least six times faster than the semi-manual VM bootstrapping and application deployment required before.

The team estimates that the company has experienced cost savings of 4-5x due to less hardware and fewer man hours needed to set up the hardware and virtual machines, metrics, and logging. Utilization of the hardware resources has been reduced as well, with containers notching two to three times more efficiency over virtual machines.

Prometheus has also had a positive impact: "It provides high availability for metrics and alerting," says Apšega. "We monitor everything starting from hardware to applications. Having all the metrics in Grafana dashboards provides great insight on our systems."

"I think that our company just started our cloud native journey. It seems like a huge road ahead, but we’re really happy that we joined it."

— Edgaras Apšega, IT Systems Engineer, Adform

All of these benefits have trickled down to individual team members, whose working lives have been changed for the better. "They used to have to get up at night to re-start some services, and now Kubernetes handles all of that," says Apšega. Adds Cibulskis: "Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore." Even the security teams have been impacted. "Security teams are always not happy," says Apšega, "and now they’re happy because they can easily inspect the containers." The company plans to remain in the data centers for now, "mostly because we want to keep all the data, to not share it in any way," says Cibulskis, "and it’s cheaper at our scale." But, Apšega says, the possibility of using a hybrid cloud for computing is intriguing: "One of the projects we’re interested in is the Virtual Kubelet that lets you spin up the working nodes on different clouds to do some computing."

Apšega, Cibulskis and their colleagues are keeping tabs on how the cloud native ecosystem develops, and are excited to contribute where they can. "I think that our company just started our cloud native journey," says Apšega. "It seems like a huge road ahead, but we’re really happy that we joined it."

案例研究：Ygrene

Mon, 01 Jan 0001 00:00:00 +0000

挑战

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

kubelet 通过 cAdvisor 收集 Pod 和容器指标。作为一个 Alpha 特性， Kubernetes 允许你通过容器运行时接口（CRI）配置收集 Pod 和容器指标。要使用基于 CRI 的收集机制，你必须启用 PodAndContainerStatsFromCRI 特性门控并使用兼容的 CRI 实现（containerd >= 1.6.0, CRI-O >= 1.23.0）。

ING Case Study

Mon, 01 Jan 0001 00:00:00 +0000

Challenge

After undergoing an agile transformation, ING realized it needed a standardized platform to support the work their developers were doing. "Our DevOps teams got empowered to be autonomous," says Infrastructure Architect Thijs Ebbers. "It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with Docker, Docker Swarm, Kubernetes, Mesos. Well, it's not really useful for a company to have one hundred wheels, instead of one good wheel.

Ingress 控制器

Mon, 01 Jan 0001 00:00:00 +0000

说明：

Kubernetes 项目推荐使用 Gateway 而不是 Ingress。 Ingress API 已经被冻结。

Job

Mon, 01 Jan 0001 00:00:00 +0000

Job 会创建一个或者多个 Pod，并将继续重试 Pod 的执行，直到指定数量的 Pod 成功终止。随着 Pod 成功结束，Job 跟踪记录成功完成的 Pod 个数。当数量达到指定的成功个数阈值时，任务（即 Job）结束。删除 Job 的操作会清除所创建的全部 Pod。挂起 Job 的操作会删除 Job 的所有活跃 Pod，直到 Job 被再次恢复执行。

kubeadm config

Mon, 01 Jan 0001 00:00:00 +0000

在 kubeadm init 执行期间，kubeadm 将 ClusterConfiguration 对象上传到你的集群的 kube-system 名字空间下名为 kubeadm-config 的 ConfigMap 对象中。然后在 kubeadm join、kubeadm reset 和 kubeadm upgrade 执行期间读取此配置。

kubelet 配置目录合并

Mon, 01 Jan 0001 00:00:00 +0000

当使用 kubelet 的 --config-dir 标志来指定存放配置的目录时，不同类型的配置会有一些特定的行为。

以下是在配置合并过程中不同数据类型的一些行为示例：

结构字段

在 YAML 结构中有两种结构字段：独立（标量类型）和嵌入式（此结构包含标量类型）。配置合并过程将处理独立构造字段和嵌入式构造字段的重载，以创建最终的 kubelet 配置。

Kubelet 设备管理器 API 版本

Mon, 01 Jan 0001 00:00:00 +0000

本页详述了 Kubernetes 设备插件 API 与不同版本的 Kubernetes 本身之间的版本兼容性。

兼容性矩阵

	`v1alpha1`	`v1beta1`
Kubernetes 1.21	-	✓
Kubernetes 1.22	-	✓
Kubernetes 1.23	-	✓
Kubernetes 1.24	-	✓
Kubernetes 1.25	-	✓
Kubernetes 1.26	-	✓

简要说明：

Kubernetes API 访问控制

Mon, 01 Jan 0001 00:00:00 +0000

本页面概述了对 Kubernetes API 的访问控制。

用户使用 kubectl、客户端库或构造 REST 请求来访问 Kubernetes API。人类用户和 Kubernetes 服务账号都可以被鉴权访问 API。当请求到达 API 时，它会经历多个阶段，如下图所示：

Kubernetes API 健康端点

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes API 服务器提供 API 端点以指示 API 服务器的当前状态。本文描述了这些 API 端点，并说明如何使用。

Kubernetes 自我修复

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 旨在通过自我修复能力来维护工作负载的健康和可用性。
它能够自动替换失败的容器，在节点不可用时重新调度工作负载，并确保系统的期望状态得以维持。

PKI 证书和要求

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 需要 PKI 证书才能进行基于 TLS 的身份验证。如果你是使用 kubeadm 安装的 Kubernetes，则会自动生成集群所需的证书。你也可以自己生成证书 --- 例如，不将私钥存储在 API 服务器上，可以让私钥更加安全。此页面说明了集群必需的证书。

本地化 Kubernetes 文档

Mon, 01 Jan 0001 00:00:00 +0000

此页面描述如何为其他语言的文档提供本地化版本。

为现有的本地化做出贡献

你可以帮助添加或改进现有本地化的内容。在 Kubernetes Slack 中，你能找到每个本地化的频道。还有一个通用的 SIG Docs Localizations Slack 频道，你可以在这里打个招呼。

边车容器

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.33 [stable]（默认启用）

边车容器是与主应用容器在同一个 Pod 中运行的辅助容器。这些容器通过提供额外的服务或功能（如日志记录、监控、安全性或数据同步）来增强或扩展主应用容器的功能，而无需直接修改主应用代码。

博客文章镜像

Mon, 01 Jan 0001 00:00:00 +0000

官方有两个 Kubernetes 博客，CNCF 也有自己的博客，你也可以在其中了解 Kubernetes。
对于主要的 Kubernetes 博客，我们（Kubernetes 项目）喜欢发表具有不同视角和特别焦点的文章，这些文章与 Kubernetes 有一定的关联。

创建 Windows HostProcess Pod

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.26 [stable]

Windows HostProcess 容器让你能够在 Windows 主机上运行容器化负载。这类容器以普通的进程形式运行，但能够在具有合适用户特权的情况下，访问主机网络名字空间、存储和设备。HostProcess 容器可用来在 Windows 节点上部署网络插件、存储配置、设备插件、kube-proxy 以及其他组件，同时不需要配置专用的代理或者直接安装主机服务。

动态卷制备

Mon, 01 Jan 0001 00:00:00 +0000

动态卷制备允许按需创建存储卷。如果没有动态制备，集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷，然后在 Kubernetes 集群创建 PersistentVolume 对象来表示这些卷。动态制备功能消除了集群管理员预先配置存储的需要。相反，它在用户创建 PersistentVolumeClaim 对象时自动制备存储。

端口和协议

Mon, 01 Jan 0001 00:00:00 +0000

当你在一个有严格网络边界的环境里运行 Kubernetes，例如拥有物理网络防火墙或者拥有公有云中虚拟网络的自有数据中心，了解 Kubernetes 组件使用了哪些端口和协议是非常有用的。

控制面

协议	方向	端口范围	目的	使用者
TCP	入站	6443	Kubernetes API 服务器	所有
TCP	入站	2379-2380	etcd 服务器客户端 API	kube-apiserver、etcd
TCP	入站	10250	kubelet API	自身、控制面
TCP	入站	10259	kube-scheduler	自身
TCP	入站	10257	kube-controller-manager	自身

尽管 etcd 的端口也列举在控制面的部分，但你也可以在外部自己托管 etcd 集群或者自定义端口。

高可用拓扑选项

Mon, 01 Jan 0001 00:00:00 +0000

本页面介绍了配置高可用（HA）Kubernetes 集群拓扑的两个选项。

你可以设置 HA 集群：

使用堆叠（stacked）控制平面节点，其中 etcd 节点与控制平面节点共存
使用外部 etcd 节点，其中 etcd 在与控制平面不同的节点上运行

在设置 HA 集群之前，你应该仔细考虑每种拓扑的优缺点。

关于 CGroup v2

Mon, 01 Jan 0001 00:00:00 +0000

在 Linux 上，控制组约束分配给进程的资源。

管理服务账号

Mon, 01 Jan 0001 00:00:00 +0000

ServiceAccount 为 Pod 中运行的进程提供了一个身份。

Pod 内的进程可以使用其关联服务账号的身份，向集群的 API 服务器进行身份认证。

有关服务账号的介绍，请参阅配置服务账号。

集群网络系统

Mon, 01 Jan 0001 00:00:00 +0000

集群网络系统是 Kubernetes 的核心部分，但是想要准确理解它的工作原理可是个不小的挑战。下面列出的是网络系统的的四个主要问题：

检查移除 Dockershim 是否对你有影响

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 的 dockershim 组件使得你可以把 Docker 用作 Kubernetes 的容器运行时。在 Kubernetes v1.24 版本中，内建组件 dockershim 被移除。

本页讲解你的集群把 Docker 用作容器运行时的运作机制，并提供使用 dockershim 时，它所扮演角色的详细信息，继而展示了一组操作，可用来检查移除 dockershim 对你的工作负载是否有影响。

节点指标数据

Mon, 01 Jan 0001 00:00:00 +0000

kubelet 在节点、卷、Pod 和容器级别收集统计信息，并在 Summary API 中输出这些信息。

你可以通过 Kubernetes API 服务器将代理的请求发送到 stats Summary API。

节点资源管理器

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 提供了一组资源管理器，用于支持延迟敏感的、高吞吐量的工作负载。资源管理器的目标是协调和优化节点资源，以支持对 CPU、设备和内存（巨页）等资源有特殊需求的 Pod。

硬件拓扑对齐策略

**拓扑管理器（Topology Manager）**是一个 kubelet 组件，旨在协调负责这些优化的组件集。整体资源管理过程通过你指定的策略进行管理。要了解更多信息，请阅读控制节点上的拓扑管理策略。

扩缩 StatefulSet

Mon, 01 Jan 0001 00:00:00 +0000

本文介绍如何扩缩 StatefulSet。StatefulSet 的扩缩指的是增加或者减少副本个数。

准备开始

StatefulSets 仅适用于 Kubernetes 1.5 及以上版本。要查看你的 Kubernetes 版本，运行 kubectl version。

配置 cgroup 驱动

Mon, 01 Jan 0001 00:00:00 +0000

本页阐述如何配置 kubelet 的 cgroup 驱动以匹配 kubeadm 集群中的容器运行时的 cgroup 驱动。

准备开始

你应该熟悉 Kubernetes 的容器运行时需求。

配置容器运行时 cgroup 驱动

容器运行时页面提到，由于 kubeadm 把 kubelet 视为一个系统服务来管理，所以对基于 kubeadm 的安装，我们推荐使用 systemd 驱动，不推荐 kubelet 默认的 cgroupfs 驱动。

使用 kubectl patch 更新 API 对象

Mon, 01 Jan 0001 00:00:00 +0000

这个任务展示如何使用 kubectl patch 就地更新 API 对象。这个任务中的练习演示了一个策略性合并 patch 和一个 JSON 合并 patch。

使用 Romana 提供 NetworkPolicy

Mon, 01 Jan 0001 00:00:00 +0000

本页展示如何使用 Romana 作为 NetworkPolicy。

准备开始

完成 kubeadm 入门指南中的 1、2、3 步。

使用 kubeadm 安装 Romana

按照容器化安装指南，使用 kubeadm 安装。

使用 Secret 安全地分发凭据

Mon, 01 Jan 0001 00:00:00 +0000

本文展示如何安全地将敏感数据（如密码和加密密钥）注入到 Pod 中。

准备开始

使用展开的方式进行并行处理

Mon, 01 Jan 0001 00:00:00 +0000

本任务展示基于一个公共的模板运行多个Jobs。你可以用这种方法来并行执行批处理任务。

适用于 Docker 用户的 kubectl

Mon, 01 Jan 0001 00:00:00 +0000

你可以使用 Kubernetes 命令行工具 kubectl 与 API 服务器进行交互。如果你熟悉 Docker 命令行工具，则使用 kubectl 非常简单。但是，Docker 命令和 kubectl 命令之间有一些区别。以下显示了 Docker 子命令，并描述了等效的 kubectl 命令。

为 Kubernetes API 生成参考文档

Mon, 01 Jan 0001 00:00:00 +0000

本页面显示了如何更新 Kubernetes API 参考文档。

为命名空间配置内存和 CPU 配额

Mon, 01 Jan 0001 00:00:00 +0000

本文介绍如何为命名空间下运行的所有 Pod 设置总的内存和 CPU 配额。你可以通过使用 ResourceQuota 对象设置配额.

污点和容忍度

Mon, 01 Jan 0001 00:00:00 +0000

节点亲和性是 Pod 的一种属性，它使 Pod 被吸引到一类特定的节点（这可能出于一种偏好，也可能是硬性要求）。 污点（Taint） 则相反——它使节点能够排斥一类特定的 Pod。

虚拟 IP 和服务代理

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 集群中的每个节点会运行一个 kube-proxy （除非你已经部署了自己的替换组件来替代 kube-proxy）。

kube-proxy 组件负责除 type 为 ExternalName 以外的 Service 实现虚拟 IP 机制。

自动扩缩工作负载

Mon, 01 Jan 0001 00:00:00 +0000

在 Kubernetes 中，你可以根据当前的资源需求扩缩工作负载。这让你的集群可以更灵活、更高效地面对资源需求的变化。

Gateway API

Mon, 01 Jan 0001 00:00:00 +0000

Gateway API 通过使用可扩展的、角色导向的、协议感知的配置机制来提供网络服务。它是一个附加组件，包含可提供动态基础设施配置和高级流量路由的 API 类别。

可观测性

Mon, 01 Jan 0001 00:00:00 +0000

在 Kubernetes 中，可观测性是通过收集和分析指标、日志和链路（通常被称为可观测性的三大支柱），以便更好地了解集群的内部状态、性能和健康情况的过程。

Admission Webhook 良好实践

Mon, 01 Jan 0001 00:00:00 +0000

本页面提供了在 Kubernetes 中设计 Admission Webhook 时的良好实践和注意事项。此信息适用于运行准入 Webhook 服务器或第三方应用程序的集群操作员，这些程序用于修改或验证你的 API 请求。

EndpointSlice

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.21 [stable]

EndpointSlices 跟踪后端端点的 IP 地址。 EndpointSlices 通常与某个关联，后端端点通常表示。

EndpointSlice API

在 Kubernetes 中，EndpointSlice 包含对一组网络端点的引用。控制面会自动为设置了选择算符的 Kubernetes Service 创建 EndpointSlice。这些 EndpointSlice 将包含对与 Service 选择算符匹配的所有 Pod 的引用。 EndpointSlice 通过唯一的 IP 地址簇、协议、端口号和 Service 名称将网络端点组织在一起。 EndpointSlice 的名称必须是合法的 DNS 子域名。

kubeadm reset

Mon, 01 Jan 0001 00:00:00 +0000

该命令尽力还原由 kubeadm init 或 kubeadm join 所做的更改。

概要

尽最大努力还原通过 'kubeadm init' 或者 'kubeadm join' 操作对主机所作的更改。

kubectl 的用法约定

Mon, 01 Jan 0001 00:00:00 +0000

kubectl 的推荐用法约定。

在可重用脚本中使用 `kubectl`

对于脚本中的稳定输出：

请求一个面向机器的输出格式，例如 -o name、-o json、-o yaml、-o go template 或 -o jsonpath。
完全限定版本。例如 jobs.v1.batch/myjob。这将确保 kubectl 不会使用其默认版本，该版本会随着时间的推移而更改。
不要依赖上下文、首选项或其他隐式状态。

子资源

你可以将 --subresource 参数用于 kubectl 命令，例如 get、patch、edit、apply 和 replace 来获取和更新所有支持子资源的资源的子资源。Kubernetes 1.35 版本中，仅支持 status, scale 和 resize 子资源。
- 对于 kubectl edit，不支持 scale 子资源。如果将 --subresource 与 kubectl edit 一起使用，并指定 scale 作为子资源，则命令将会报错。
针对子资源的 API 协定与完整资源相同。在更新 status 子资源为一个新值时，请记住，子资源可能是潜在的由控制器调和为不同的值。

最佳实践

`kubectl run`

若希望 kubectl run 满足基础设施即代码的要求：

Kubernetes z-pages

Mon, 01 Jan 0001 00:00:00 +0000

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

Kubernetes 的核心组件可以暴露一系列 z-endpoints，以便用户更轻松地调试他们的集群及其组件。这些端点仅用于人工检查，以获取组件二进制文件的实时调试信息。请不要自动抓取这些端点返回的数据；在 Kubernetes 1.35 中，这些是 Alpha 特性，响应格式可能会在未来版本中发生变化。

Pod 水平自动扩缩

Mon, 01 Jan 0001 00:00:00 +0000

在 Kubernetes 中，HorizontalPodAutoscaler 自动更新工作负载资源（例如 Deployment 或者 StatefulSet），目的是容量自动扩缩以满足需求。

从 dockershim 迁移遥测和安全代理

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 对与 Docker Engine 直接集成的支持已被弃用且已经被删除。大多数应用程序不直接依赖于托管容器的运行时。但是，仍然有大量的遥测和监控代理依赖 Docker 来收集容器元数据、日志和指标。本文汇总了一些如何探查这些依赖的信息以及如何迁移这些代理去使用通用工具或其他容器运行时的参考链接。

调度框架

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.19 [stable]

调度框架是面向 Kubernetes 调度器的一种插件架构，它由一组直接编译到调度程序中的“插件” API 组成。这些 API 允许大多数调度功能以插件的形式实现，同时使调度“核心”保持简单且可维护。请参考调度框架的设计提案获取框架设计的更多技术信息。

发布后沟通

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 的发布沟通（Release Comms） 团队（隶属于 SIG Release）负责管理发布相关的公告，这些公告会发布在主项目博客上。

基于角色的访问控制良好实践

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes RBAC 是一项重要的安全控制措施，用于保证集群用户和工作负载只能访问履行自身角色所需的资源。在为集群用户设计权限时，请务必确保集群管理员知道可能发生特权提级的地方，降低因过多权限而导致安全事件的风险。

集群管理员使用动态资源分配的良好实践

Mon, 01 Jan 0001 00:00:00 +0000

本文介绍在利用动态资源分配（DRA）配置 Kubernetes 集群时的良好实践。这些指示说明适用于集群管理员。

DRA 是通过多个不同的 API 进行编排的。使用鉴权工具（如 RBAC 或其他方案）根据用户的角色来控制对相关 API 的访问权限。

卷快照

Mon, 01 Jan 0001 00:00:00 +0000

在 Kubernetes 中，卷快照 是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes 的持久卷。

介绍

与 PersistentVolume 和 PersistentVolumeClaim 这两个 API 资源用于给用户和管理员制备卷类似， VolumeSnapshotContent 和 VolumeSnapshot 这两个 API 资源用于给用户和管理员创建卷快照。

利用 kubeadm 创建高可用集群

Mon, 01 Jan 0001 00:00:00 +0000

本文讲述了使用 kubeadm 设置一个高可用的 Kubernetes 集群的两种不同方式：

临时容器

Mon, 01 Jan 0001 00:00:00 +0000

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

本页面概述了临时容器：一种特殊的容器，该容器在现有 Pod 中临时运行，以便完成用户发起的操作，例如故障排查。你会使用临时容器来检查服务，而不是用它来构建应用程序。

配置 Pod 的服务质量

Mon, 01 Jan 0001 00:00:00 +0000

本页介绍怎样配置 Pod 以让其归属于特定的服务质量类（Quality of Service class，QoS class）. Kubernetes 在 Node 资源不足时使用 QoS 类来就驱逐 Pod 作出决定。

配置命名空间下 Pod 配额

Mon, 01 Jan 0001 00:00:00 +0000

本文主要介绍如何在命名空间中设置可运行 Pod 总数的配额。你可以通过使用 ResourceQuota 对象来配置配额。

启用或禁用特性门控

Mon, 01 Jan 0001 00:00:00 +0000

本页介绍如何启用或禁用特性门控（feature gates），以便在你的集群中控制特定的 Kubernetes 特性。启用特性门控可以让你在特性正式发布（GA）之前，测试并使用 Alpha 或 Beta 特性。

说明：

对于某些稳定（GA）的特性门控，你也可以禁用它们，通常只允许在 GA 之后的一个次要版本中这样做；但如果你这样做，你的集群可能不再符合 Kubernetes 一致性（conformance）要求。

日志架构

Mon, 01 Jan 0001 00:00:00 +0000

应用日志可以让你了解应用内部的运行状况。日志对调试问题和监控集群活动非常有用。大部分现代化应用都有某种日志记录机制。同样地，容器引擎也被设计成支持日志记录。针对容器化应用，最简单且最广泛采用的日志记录方式就是写入标准输出和标准错误流。

容器运行时接口（CRI）

Mon, 01 Jan 0001 00:00:00 +0000

CRI 是一个插件接口，它使 kubelet 能够使用各种容器运行时，无需重新编译集群组件。

删除 StatefulSet

Mon, 01 Jan 0001 00:00:00 +0000

本任务展示如何删除 StatefulSet。

准备开始

本任务假设在你的集群上已经运行了由 StatefulSet 创建的应用。

删除 StatefulSet

你可以像删除 Kubernetes 中的其他资源一样删除 StatefulSet：使用 kubectl delete 命令，并按文件或者名字指定 StatefulSet。

使用 HostAliases 向 Pod /etc/hosts 文件添加条目

Mon, 01 Jan 0001 00:00:00 +0000

当 DNS 配置以及其它选项不合理的时候，通过向 Pod 的 /etc/hosts 文件中添加条目，可以在 Pod 级别覆盖对主机名的解析。你可以通过 PodSpec 的 HostAliases 字段来添加这些自定义条目。

使用 kubeconfig 文件组织集群访问

Mon, 01 Jan 0001 00:00:00 +0000

使用 kubeconfig 文件来组织有关集群、用户、命名空间和身份认证机制的信息。 kubectl 命令行工具使用 kubeconfig 文件来查找选择集群所需的信息，并与集群的 API 服务器进行通信。

说明：

用于配置集群访问的文件称为 kubeconfig 文件。这是引用到配置文件的通用方法，并不意味着有一个名为 kubeconfig 的文件。

使用 Kubernetes API 访问集群

Mon, 01 Jan 0001 00:00:00 +0000

本页展示了如何使用 Kubernetes API 访问集群。

准备开始

使用 Pod 失效策略处理可重试和不可重试的 Pod 失效

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.31 [stable]（默认启用）

本文向你展示如何结合默认的 Pod 回退失效策略来使用 Pod 失效策略，以改善 Job 内处理容器级别或 Pod 级别的失效。

使用 Weave Net 提供 NetworkPolicy

Mon, 01 Jan 0001 00:00:00 +0000

本页展示如何使用 Weave Net 提供 NetworkPolicy。

准备开始

你需要拥有一个 Kubernetes 集群。按照 kubeadm 入门指南来启动一个。

安装 Weave Net 插件

按照通过插件集成 Kubernetes 指南执行安装。

使用存储版本迁移功能来迁移 Kubernetes 对象

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.35 [beta]（默认禁用）

Kubernetes 依赖主动重写的 API 数据来支持与静态存储相关的一些维护活动。两个著名的例子是已存储资源的版本化模式（即针对给定资源的首选存储模式从 v1 更改为 v2）和静态加密（即基于数据加密方式的变化来重写过时的数据）。

使用服务来访问集群中的应用

Mon, 01 Jan 0001 00:00:00 +0000

本文展示如何创建一个 Kubernetes 服务对象，能让外部客户端访问在集群中运行的应用。该服务为一个应用的两个运行实例提供负载均衡。

准备开始

探索 Pod 及其端点的终止行为

Mon, 01 Jan 0001 00:00:00 +0000

一旦你参照使用 Service 连接到应用中概述的那些步骤使用 Service 连接到了你的应用，你就有了一个持续运行的多副本应用暴露在了网络上。本教程帮助你了解 Pod 的终止流程，探索实现连接排空的几种方式。

图表指南

Mon, 01 Jan 0001 00:00:00 +0000

本指南为你展示如何创建、编辑和分享基于 Mermaid JavaScript 库的图表。 Mermaid.js 允许你使用简单的、类似于 Markdown 的语法来在 Markdown 文件中生成图表。你也可以使用 Mermaid 来创建 .svg 或 .png 图片文件，将其添加到你的文档中。

证书和证书签名请求

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.19 [stable]

Kubernetes 证书和信任包（trust bundle）API 可以通过为 Kubernetes API 的客户端提供编程接口，实现 X.509 凭据的自动化制备，从而请求并获取证书颁发机构（CA）发布的 X.509 证书。

注解

Mon, 01 Jan 0001 00:00:00 +0000

你可以使用 Kubernetes 注解为对象附加任意的非标识的元数据。客户端程序（例如工具和库）能够获取这些元数据信息。

为对象附加元数据

你可以使用标签或注解将元数据附加到 Kubernetes 对象。标签可以用来选择对象和查找满足某些条件的对象集合。相反，注解不用于标识和选择对象。注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符。可以在同一对象的元数据中同时使用标签和注解。

卷快照类

Mon, 01 Jan 0001 00:00:00 +0000

本文档描述了 Kubernetes 中 VolumeSnapshotClass 的概念。建议熟悉卷快照（Volume Snapshots）和存储类（Storage Class）。

介绍

就像 StorageClass 为管理员提供了一种在配置卷时描述存储“类”的方法， VolumeSnapshotClass 提供了一种在配置卷快照时描述存储“类”的方法。

Kubernetes 中的 Windows 容器

Mon, 01 Jan 0001 00:00:00 +0000

在许多组织中，所运行的很大一部分服务和应用是 Windows 应用。 Windows 容器提供了一种封装进程和包依赖项的方式，从而简化了 DevOps 实践，令 Windows 应用同样遵从云原生模式。

动态资源分配

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.35 [stable]（默认启用）

本页描述 Kubernetes 中的 动态资源分配（DRA）。

CSI 卷克隆

Mon, 01 Jan 0001 00:00:00 +0000

本文档介绍 Kubernetes 中克隆现有 CSI 卷的概念。阅读前建议先熟悉卷。

介绍

CSI 卷克隆功能增加了通过在 dataSource 字段中指定存在的 PVC，来表示用户想要克隆的卷（Volume）。

kubeadm token

Mon, 01 Jan 0001 00:00:00 +0000

如使用引导令牌进行身份验证所述，引导令牌用于在即将加入集群的节点和控制平面节点间建立双向认证。

kubeadm init 创建了一个有效期为 24 小时的令牌，下面的命令允许你管理令牌，也可以创建和管理新的令牌。

kubectl 用户偏好设置（kuberc）

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes 1.34 [beta]

Kubernetes kuberc 配置文件允许你定义 kubectl 的偏好设置，例如默认选项和命令别名。与 kubeconfig 文件不同，kuberc 配置文件不包含集群详情、用户名或密码。

Kubernetes Secret 良好实践

Mon, 01 Jan 0001 00:00:00 +0000

在 Kubernetes 中，Secret 是这样一个对象： secret 用于存储敏感信息，如密码、OAuth 令牌和 SSH 密钥。

Kubernetes 控制平面组件的兼容版本

Mon, 01 Jan 0001 00:00:00 +0000

自 v1.32 版本发布以来，我们为 Kubernetes 控制平面组件引入了可配置的版本兼容性和仿真选项，为集群管理员提供更多控制选项并增加可用的细粒度步骤来让升级更加安全。

仿真版本

仿真选项通过控制平面组件的 --emulated-version 参数来设置。此选项允许控制平面组件仿真 Kubernetes 早期版本的行为（API、特性等）。

Kubernetes 系统组件指标

Mon, 01 Jan 0001 00:00:00 +0000

通过系统组件指标可以更好地了解系统组个内部发生的情况。系统组件指标对于构建仪表板和告警特别有用。

编组调度（Gang Scheduling）

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.35 [alpha]（默认禁用）

编组调度（Gang Scheduling）确保一组 Pod 以 全有或全无（all-or-nothing） 的方式进行调度。如果集群无法容纳整个组（或某确定的最小 Pod 数量），则不会将任何 Pod 绑定到节点上。

调度器性能调优

Mon, 01 Jan 0001 00:00:00 +0000

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

作为 kubernetes 集群的默认调度器， kube-scheduler 主要负责将 Pod 调度到集群的 Node 上。

在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为可调度 Node。调度器先在集群中找到一个 Pod 的可调度 Node，然后根据一系列函数对这些可调度 Node 打分，之后选出其中得分最高的 Node 来运行 Pod。最后，调度器将这个调度决定告知 kube-apiserver，这个过程叫做绑定（Binding）。

干扰（Disruptions）

Mon, 01 Jan 0001 00:00:00 +0000

本指南针对的是希望构建高可用性应用的应用所有者，他们有必要了解可能发生在 Pod 上的干扰类型。

文档同样适用于想要执行自动化集群操作（例如升级和自动扩展集群）的集群管理员。

垃圾收集

Mon, 01 Jan 0001 00:00:00 +0000

垃圾收集（Garbage Collection）是 Kubernetes 用于清理集群资源的各种机制的统称。垃圾收集允许系统清理如下资源：

终止的 Pod
已完成的 Job
不再存在属主引用的对象
未使用的容器和容器镜像
动态制备的、StorageClass 回收策略为 Delete 的 PV 卷
阻滞或者过期的 CertificateSigningRequest (CSR)
在以下情形中删除了的节点对象：
- 当集群使用云控制器管理器运行于云端时；
- 当集群使用类似于云控制器管理器的插件运行在本地环境中时。
节点租约对象

属主与依赖

Kubernetes 中很多对象通过属主引用 链接到彼此。属主引用（Owner Reference）可以告诉控制面哪些对象依赖于其他对象。 Kubernetes 使用属主引用来为控制面以及其他 API 客户端在删除某对象时提供一个清理关联资源的机会。在大多数场合，Kubernetes 都是自动管理属主引用的。

强制删除 StatefulSet 中的 Pod

Mon, 01 Jan 0001 00:00:00 +0000

本文介绍如何删除 StatefulSet 管理的 Pod，并解释这样操作时需要记住的一些注意事项。

准备开始

这是一项相当高级的任务，并且可能会违反 StatefulSet 固有的某些属性。
请先熟悉下面列举的注意事项再开始操作。

StatefulSet 注意事项

在正常操作 StatefulSet 时，永远不需要强制删除 StatefulSet 管理的 Pod。 StatefulSet 控制器负责创建、扩缩和删除 StatefulSet 管理的 Pod。此控制器尽力确保指定数量的从序数 0 到 N-1 的 Pod 处于活跃状态并准备就绪。StatefulSet 确保在任何时候，集群中最多只有一个具有给定标识的 Pod。这就是所谓的由 StatefulSet 提供的最多一个（At Most One） Pod 的语义。

设置 Konnectivity 服务

Mon, 01 Jan 0001 00:00:00 +0000

Konnectivity 服务为控制平面提供集群通信的 TCP 级别代理。

准备开始

你需要有一个 Kubernetes 集群，并且 kubectl 命令可以与集群通信。建议在至少有两个不充当控制平面主机的节点的集群上运行本教程。如果你还没有集群，可以使用 minikube 创建一个集群。

使用 kubeadm 创建一个高可用 etcd 集群

Mon, 01 Jan 0001 00:00:00 +0000

默认情况下，kubeadm 在每个控制平面节点上运行一个本地 etcd 实例。也可以使用外部的 etcd 集群，并在不同的主机上提供 etcd 实例。这两种方法的区别在高可用拓扑的选项页面中阐述。

使用 Service 把前端连接到后端

Mon, 01 Jan 0001 00:00:00 +0000

本任务会描述如何创建前端（Frontend）微服务和后端（Backend）微服务。后端微服务是一个 hello 欢迎程序。前端通过 nginx 和一个 Kubernetes 服务暴露后端所提供的服务。

教程目标

使用部署对象（Deployment object）创建并运行一个 hello 后端微服务
使用一个 Service 对象将请求流量发送到后端微服务的多个副本
同样使用一个 Deployment 对象创建并运行一个 nginx 前端微服务
配置前端微服务将请求流量发送到后端微服务
使用 type=LoadBalancer 的 Service 对象将前端微服务暴露到集群外部

准备开始

网络策略

Mon, 01 Jan 0001 00:00:00 +0000

如果你希望针对 TCP、UDP 和 SCTP 协议在 IP 地址或端口层面控制网络流量，则你可以考虑为集群中特定应用使用 Kubernetes 网络策略（NetworkPolicy）。 NetworkPolicy 是一种以应用为中心的结构，允许你设置如何允许 Pod 与网络上的各类网络“实体” （我们这里使用实体以避免过度使用诸如“端点”和“服务”这类常用术语，这些术语在 Kubernetes 中有特定含义）通信。 NetworkPolicy 适用于一端或两端与 Pod 的连接，与其他连接无关。

为节点发布扩展资源

Mon, 01 Jan 0001 00:00:00 +0000

本文展示了如何为节点指定扩展资源（Extended Resource）。扩展资源允许集群管理员发布节点级别的资源，这些资源在不进行发布的情况下无法被 Kubernetes 感知。

准备开始

为容器分派扩展资源

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.35 [stable]

本文介绍如何为容器指定扩展资源。

准备开始

已完成 Job 的自动清理

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.23 [stable]

当你的 Job 已结束时，将 Job 保留在 API 中（而不是立即删除 Job）很有用，这样你就可以判断 Job 是成功还是失败。

撰写新主题

Mon, 01 Jan 0001 00:00:00 +0000

本页面展示如何为 Kubernetes 文档库创建新主题。

准备开始

如发起 PR中所述，创建 Kubernetes 文档库的派生副本。

选择页面类型

当你准备编写一个新的主题时，考虑一下最适合你的内容的页面类型：

字段选择算符

Mon, 01 Jan 0001 00:00:00 +0000

“字段选择算符（Field selectors）”允许你根据一个或多个资源字段的值筛选 Kubernetes 对象。下面是一些使用字段选择算符查询的例子：

作为博客写作伙伴提供帮助

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 有两个官方博客，同时 CNCF 也有自己的博客，你也可以在其中撰写与 Kubernetes 相关的内容。
阅读为 Kubernetes 博客贡献内容以了解这两个博客的详细信息。

Kubernetes 对象状态的指标

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes API 中 Kubernetes 对象的状态可以被公开为指标。一个名为 kube-state-metrics 的插件代理可以连接到 Kubernetes API 服务器并公开一个 HTTP 端点，提供集群中各个对象的状态所生成的指标。此代理公开了关于对象状态的各种信息，如标签和注解、启动和终止时间、对象当前所处的状态或阶段。例如，针对运行在 Pod 中的容器会创建一个 kube_pod_container_info 指标。其中包括容器的名称、所属的 Pod 的名称、Pod 所在的命名空间、容器镜像的名称、镜像的 ID、容器规约中的镜像名称、运行中容器的 ID 和用作标签的 Pod ID。

Windows 节点的资源管理

Mon, 01 Jan 0001 00:00:00 +0000

本页概述了 Linux 和 Windows 在资源管理方式上的区别。

在 Linux 节点上，cgroup 用作资源控制的 Pod 边界。在这个边界内创建容器以便于隔离网络、进程和文件系统。 Linux cgroup API 可用于收集 CPU、I/O 和内存使用统计数据。

在 Kubernetes 中运行 Windows 容器的指南

Mon, 01 Jan 0001 00:00:00 +0000

本文提供了一些参考演示步骤，方便你使用 Kubernetes 运行 Windows 容器。本文还重点介绍了 Kubernetes 中专为 Windows 设计的一些特有功能。

CronJob

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.21 [stable]

CronJob 创建基于时隔重复调度的 Job。

Finalizers

Mon, 01 Jan 0001 00:00:00 +0000

Finalizer 是带有命名空间的键，告诉 Kubernetes 等到特定的条件被满足后，再完全删除被标记为删除的资源。 Finalizer 提醒控制器清理被删除的对象拥有的资源。

kubeadm version

Mon, 01 Jan 0001 00:00:00 +0000

此命令用来输出 kubeadm 的版本。

概要

打印 kubeadm 的版本。

kubeadm version [flags]

选项

-h, --help

version 操作的帮助命令。

kubelet systemd 看门狗

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.32 [beta]（默认启用）

在 Linux 节点上，Kubernetes 1.35 支持与 systemd 集成，以允许操作系统监视程序恢复失败的 kubelet。这种集成默认并未被启用。它可以作为一个替代方案，通过定期请求 kubelet 的 /healthz 端点进行健康检查。如果 kubelet 在设定的超时时限内未对看门狗做出响应，看门狗将杀死 kubelet。

Seccomp 和 Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Seccomp 表示安全计算（Secure Computing）模式，自 2.6.12 版本以来，一直是 Linux 内核的一个特性。它可以用来沙箱化进程的权限，限制进程从用户态到内核态的调用。 Kubernetes 能使你自动将加载到节点上的 seccomp 配置文件应用到你的 Pod 和容器。

Service 与 Pod 的 DNS

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 为 Service 和 Pod 创建 DNS 记录。你可以使用稳定的 DNS 名称而非 IP 地址访问 Service。

创建外部负载均衡器

Mon, 01 Jan 0001 00:00:00 +0000

本文展示如何创建一个外部负载均衡器。

创建服务时，你可以选择自动创建云网络负载均衡器。负载均衡器提供外部可访问的 IP 地址，可将流量发送到集群节点上的正确端口上（假设集群在支持的环境中运行，并配置了正确的云负载均衡器驱动包）。

存储容量

Mon, 01 Jan 0001 00:00:00 +0000

存储容量是有限的，并且会因为运行 Pod 的节点不同而变化：网络存储可能并非所有节点都能够访问，或者对于某个节点存储是本地的。

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

本页面描述了 Kubernetes 如何跟踪存储容量以及调度程序如何为了余下的尚未挂载的卷使用该信息将 Pod 调度到能够访问到足够存储容量的节点上。如果没有跟踪存储容量，调度程序可能会选择一个没有足够容量来提供卷的节点，并且需要多次调度重试。

多租户

Mon, 01 Jan 0001 00:00:00 +0000

此页面概述了集群多租户的可用配置选项和最佳实践。

共享集群可以节省成本并简化管理。然而，共享集群也带来了诸如安全性、公平性和管理嘈杂邻居等挑战。

集群可以通过多种方式共享。在某些情况下，不同的应用可能会在同一个集群中运行。在其他情况下，同一应用的多个实例可能在同一个集群中运行，每个实例对应一个最终用户。所有这些类型的共享经常使用一个总括术语 多租户（Multi-Tenancy） 来表述。

节点状态

Mon, 01 Jan 0001 00:00:00 +0000

在 Kubernetes 中，节点的状态是管理 Kubernetes 集群的一个关键方面。在本文中，我们将简要介绍如何监控和维护节点状态以确保集群的健康和稳定。

节点状态字段

一个节点的状态包含以下信息:

配置 Pod 以使用卷进行存储

Mon, 01 Jan 0001 00:00:00 +0000

此页面展示了如何配置 Pod 以使用卷进行存储。

使用 CertificateSigningRequest 为 Kubernetes API 客户端颁发证书

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 允许你使用公钥基础设施 (PKI) 对你的集群进行身份认证，这类似于对客户端进行身份认证。

使用 kubeadm 进行证书管理

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.15 [stable]

由 kubeadm 生成的客户端证书在 1 年后到期。本页说明如何使用 kubeadm 管理证书续订，同时也涵盖其他与 kubeadm 证书管理相关的说明。

Kubernetes 项目建议及时升级到最新的补丁版本，并确保你正在运行受支持的 Kubernetes 次要版本。遵循这一建议有助于你确保安全。

使用 kubeadm 配置集群中的每个 kubelet

Mon, 01 Jan 0001 00:00:00 +0000

说明： 自 1.24 版起，Dockershim 已从 Kubernetes 项目中移除。阅读 Dockershim 移除的常见问题了解更多详情。

特性状态： Kubernetes v1.11 [stable]

kubeadm CLI 工具的生命周期与 kubelet 解耦；kubelet 是一个守护程序，在 Kubernetes 集群中的每个节点上运行。当 Kubernetes 初始化或升级时，kubeadm CLI 工具由用户执行，而 kubelet 始终在后台运行。

系统日志

Mon, 01 Jan 0001 00:00:00 +0000

系统组件的日志记录集群中发生的事件，这对于调试非常有用。你可以配置日志的精细度，以展示更多或更少的细节。日志可以是粗粒度的，如只显示组件内的错误，也可以是细粒度的，如显示事件的每一个跟踪步骤（比如 HTTP 访问日志、pod 状态更新、控制器动作或调度器决策）。

页面内容类型

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 文档包含以下几种页面内容类型：

概念（Concept）
任务（Task）
教程（Tutorial）
参考（Reference）

内容章节

每种页面内容类型都有一些使用 Markdown 注释和 HTML 标题定义的章节。你可以使用 heading 短代码将内容标题添加到你的页面中。注释和标题有助于维护对应页面内容类型的结构组织。

资源装箱

Mon, 01 Jan 0001 00:00:00 +0000

在 kube-scheduler 的调度插件 NodeResourcesFit 中存在两种支持资源装箱（bin packing）的策略：MostAllocated 和 RequestedToCapacityRatio。

使用 MostAllocated 策略启用资源装箱

MostAllocated 策略基于资源的利用率来为节点计分，优选分配比率较高的节点。针对每种资源类型，你可以设置一个权重值以改变其对节点得分的影响。

自动扩缩集群 DNS 服务

Mon, 01 Jan 0001 00:00:00 +0000

本页展示了如何在你的 Kubernetes 集群中启用和配置 DNS 服务的自动扩缩功能。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

Pod QoS 类

Mon, 01 Jan 0001 00:00:00 +0000

本页介绍 Kubernetes 中的 服务质量（Quality of Service，QoS） 类，阐述 Kubernetes 如何根据为 Pod 中的容器指定的资源约束为每个 Pod 设置 QoS 类。 Kubernetes 依赖这种分类来决定当 Node 上没有足够可用资源时要驱逐哪些 Pod。

Pod 主机名

Mon, 01 Jan 0001 00:00:00 +0000

本文讲述如何设置 Pod 的主机名、配置主机名后的潜在副作用以及底层机制。

默认 Pod 主机名

当 Pod 被创建时，其主机名（从 Pod 内部观察）来源于 Pod 的 metadata.name 值。主机名和其对应的完全限定域名（FQDN）都会被设置为 metadata.name 值（从 Pod 的角度）。

IPv4/IPv6 双协议栈

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.23 [stable]

IPv4/IPv6 双协议栈网络能够将 IPv4 和 IPv6 地址分配给 Pod 和 Service。

kubeadm alpha

Mon, 01 Jan 0001 00:00:00 +0000

注意：

kubeadm alpha 提供了一组可用于收集社区反馈的预览性质功能。请试用这些功能并给我们提供反馈！

目前在 kubeadm alpha 之下没有试验性质的命令。

接下来

用来启动引导 Kubernetes 控制平面节点的 kubeadm init 命令
用来将节点连接到集群的 kubeadm join 命令
用来还原 kubeadm init 或 kubeadm join 操作对主机所做的任何更改的 kubeadm reset 命令

kubeadm certs

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm certs 提供管理证书的工具。关于如何使用这些命令的细节，可参见使用 kubeadm 管理证书。

kubeadm certs

用来操作 Kubernetes 证书的一组命令。

概览

概要

处理 Kubernetes 证书相关的命令。

kubeadm certs [flags]

选项

-h, --help

certs 操作的帮助命令。

kubeadm init phase

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm init phase 能确保调用引导过程的原子步骤。因此，如果希望自定义应用，则可以让 kubeadm 做一些工作，然后填补空白。

kubeadm init phase 与 kubeadm init 工作流一致，后台都使用相同的代码。

kubeadm join phase

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm join phase 使你能够调用 join 过程的基本原子步骤。因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。

kubeadm join phase 与 kubeadm join 工作流程一致，后台都使用相同的代码。

kubeadm kubeconfig

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm kubeconfig 提供用来管理 kubeconfig 文件的工具。

如果希望查看如何使用 kubeadm kubeconfig user 的示例，请参阅为其他用户生成 kubeconfig 文件。

kubeadm kubeconfig

概述

概要

kubeconfig 文件工具。

选项

-h, --help

kubeconfig 操作的帮助命令。

从父命令继承的选项

--rootfs string

到“真实”主机根文件系统的路径。设置此标志将导致 kubeadm 切换到所提供的路径。

kubeadm reset phase

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm reset phase 使你能够调用 reset 过程的基本原子步骤。因此，如果希望执行自定义操作，你可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。

kubeadm reset phase 与 kubeadm reset 工作流程一致，后台都使用相同的代码。

Kubernetes API 服务器旁路风险

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes API 服务器是外部（用户和服务）与集群交互的主要入口。

API 服务器作为交互的主要入口，还提供了几种关键的内置安全控制，例如审计日志和准入控制器。但有一些方式可以绕过这些安全控制从而修改集群的配置或内容。

Pod 优先级和抢占

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.14 [stable]

Pod 可以有优先级。优先级表示一个 Pod 相对于其他 Pod 的重要性。如果一个 Pod 无法被调度，调度程序会尝试抢占（驱逐）较低优先级的 Pod，以使悬决 Pod 可以被调度。

ReplicationController

Mon, 01 Jan 0001 00:00:00 +0000

说明：

现在推荐使用配置 ReplicaSet 的 Deployment 来建立副本管理机制。

ReplicationController 确保在任何时候都有特定数量的 Pod 副本处于运行状态。换句话说，ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。

从轮询切换为基于 CRI 事件的更新来获取容器状态

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.26 [alpha]（默认禁用）

本页展示了如何迁移节点以使用基于事件的更新来获取容器状态。与依赖轮询的传统方法相比，基于事件的实现可以减少 kubelet 对节点资源的消耗。你可以将这个特性称为事件驱动的 Pod 生命周期事件生成器 (PLEG)。这是在 Kubernetes 项目内部针对关键实现细节所用的名称。

改变默认 StorageClass

Mon, 01 Jan 0001 00:00:00 +0000

本文展示了如何改变默认的 Storage Class，它用于为没有特殊需求的 PersistentVolumeClaims 配置 volumes。

准备开始

加固指南 - 调度器配置

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 调度器是控制平面的关键组件之一。

加固指南 - 身份认证机制

Mon, 01 Jan 0001 00:00:00 +0000

选择合适的身份认证机制是确保集群安全的一个重要方面。 Kubernetes 提供了多种内置机制，当为你的集群选择最好的身份认证机制时需要谨慎考虑每种机制的优缺点。

将 PersistentVolume 的访问模式更改为 ReadWriteOncePod

Mon, 01 Jan 0001 00:00:00 +0000

本文演示了如何将现有 PersistentVolume 的访问模式更改为使用 ReadWriteOncePod。

准备开始

内容组织

Mon, 01 Jan 0001 00:00:00 +0000

本网站使用了 Hugo。在 Hugo 中，内容组织是一个核心概念。

说明：

Hugo 提示： 用 hugo server --navigateToChanged 命令启动 Hugo 以进行内容编辑会话。

页面列表

页面顺序

文档侧方菜单、文档页面浏览器等以 Hugo 的默认排序顺序列出。Hugo 会按照权重（从 1 开始）、日期（最新的排最前面）排序，最后按链接标题排序。

配置 Pod 以使用 PersistentVolume 作为存储

Mon, 01 Jan 0001 00:00:00 +0000

本文将向你介绍如何配置 Pod 使用 PersistentVolumeClaim 作为存储。以下是该过程的总结：

属主与附属

Mon, 01 Jan 0001 00:00:00 +0000

在 Kubernetes 中，一些对象是其他对象的“属主（Owner）”。例如，ReplicaSet 是一组 Pod 的属主。具有属主的对象是属主的“附属（Dependent）”。

特定于节点的卷数限制

Mon, 01 Jan 0001 00:00:00 +0000

此页面描述了各个云供应商可挂接至一个节点的最大卷数。

谷歌、亚马逊和微软等云供应商通常对可以挂接到节点的卷数量进行限制。 Kubernetes 需要尊重这些限制。否则，在节点上调度的 Pod 可能会卡住去等待卷的挂接。

为 kubectl 命令集生成参考文档

Mon, 01 Jan 0001 00:00:00 +0000

本页面描述了如何生成 kubectl 命令参考。

说明：

本主题描述了如何为 kubectl 命令生成参考文档，如 kubectl apply 和 kubectl taint。本主题没有讨论如何生成 kubectl 组件选项的参考页面。相关说明请参见为 Kubernetes 组件和工具生成参考页面。

准备开始

需求

你需要一台 Linux 或 macOS 机器。

重新配置 kubeadm 集群

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm 不支持自动重新配置部署在托管节点上的组件的方式。一种自动化的方法是使用自定义的 operator。

要修改组件配置，你必须手动编辑磁盘上关联的集群对象和文件。本指南展示了实现 kubeadm 集群重新配置所需执行的正确步骤顺序。

追踪 Kubernetes 系统组件

Mon, 01 Jan 0001 00:00:00 +0000

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

系统组件追踪功能记录各个集群操作的时延信息和这些操作之间的关系。

Kubernetes 组件基于 gRPC 导出器的 OpenTelemetry 协议发送追踪信息，并用 OpenTelemetry Collector 收集追踪信息，再将其转交给追踪系统的后台。

从 PodSecurityPolicy 映射到 Pod 安全性标准

Mon, 01 Jan 0001 00:00:00 +0000

下面的表格列举了 PodSecurityPolicy 对象上的配置参数，这些字段是否会变更或检查 Pod 配置，以及这些配置值如何映射到 Pod 安全性标准（Pod Security Standards）之上。

对于每个可应用的参数，表格中给出了 Baseline 和 Restricted 配置下可接受的取值。对这两种配置而言不可接受的取值均归入 Privileged 配置下。“无意见”意味着对所有 Pod 安全性标准而言所有取值都可接受。

HorizontalPodAutoscaler 演练

Mon, 01 Jan 0001 00:00:00 +0000

HorizontalPodAutoscaler（简称 HPA ）自动更新工作负载资源（例如 Deployment 或者 StatefulSet），目的是自动扩缩工作负载以满足需求。

Kubernetes 中的代理

Mon, 01 Jan 0001 00:00:00 +0000

本文讲述了 Kubernetes 中所使用的代理。

代理

用户在使用 Kubernetes 的过程中可能遇到几种不同的代理（proxy）：

kubectl proxy：

安全检查清单

Mon, 01 Jan 0001 00:00:00 +0000

本清单旨在提供一个基本的指导列表，其中包含链接，指向各个主题的更为全面的文档。此清单不求详尽无遗，是预计会不断演化的。

更改 PersistentVolume 的回收策略

Mon, 01 Jan 0001 00:00:00 +0000

本文展示了如何更改 Kubernetes PersistentVolume 的回收策略。

准备开始

节点压力驱逐

Mon, 01 Jan 0001 00:00:00 +0000

节点压力驱逐是 kubelet 主动终止 Pod 以回收节点上资源的过程。

kubelet 监控集群节点的内存、磁盘空间和文件系统的 inode 等资源。当这些资源中的一个或者多个达到特定的消耗水平， kubelet 可以主动地使节点上一个或者多个 Pod 失效，以回收资源防止饥饿。

进阶贡献

Mon, 01 Jan 0001 00:00:00 +0000

如果你已经了解如何贡献新内容和评阅他人工作，并准备了解更多贡献的途径，请阅读此文。你需要使用 Git 命令行工具和其他工具做这些工作。

提出改进建议

SIG Docs 的成员可以提出改进建议。

卷健康监测

Mon, 01 Jan 0001 00:00:00 +0000

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

CSI 卷健康监测支持 CSI 驱动从底层的存储系统着手，探测异常的卷状态，并以事件的形式上报到 PVC 或 Pod.

列出集群中所有运行容器的镜像

Mon, 01 Jan 0001 00:00:00 +0000

本文展示如何使用 kubectl 来列出集群中所有运行 Pod 的容器的镜像

准备开始

配置 Pod 使用投射卷作存储

Mon, 01 Jan 0001 00:00:00 +0000

本文介绍怎样通过 projected 卷将现有的多个卷资源挂载到相同的目录。当前，secret、configMap、downwardAPI 和 serviceAccountToken 卷可以被投射。

说明：

serviceAccountToken 不是一种卷类型。

准备开始

实现细节

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.10 [stable]

kubeadm init 和 kubeadm join 结合在一起为从头开始创建最基本的 Kubernetes 集群提供了良好的用户体验，这与最佳实践一致。但是，kubeadm 如何做到这一点可能并不明显。

本文档提供了更多幕后的详细信息，旨在分享有关 Kubernetes 集群最佳实践的知识。

使用 kubeadm 支持双协议栈

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.23 [stable]

你的集群包含双协议栈组网支持，这意味着集群网络允许你在两种地址族间任选其一。在集群中，控制面可以为同一个 Pod 或者 Service 同时赋予 IPv4 和 IPv6 地址。

拓扑感知路由

Mon, 01 Jan 0001 00:00:00 +0000

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

说明：

在 Kubernetes 1.27 之前，此特性称为拓扑感知提示（Topology Aware Hint）。

为指标生成参考文档

Mon, 01 Jan 0001 00:00:00 +0000

本页演示如何生成指标参考文档。

准备开始

需求

你需要一台 Linux 或 macOS 机器。

针对 Pod 和容器的 Linux 内核安全约束

Mon, 01 Jan 0001 00:00:00 +0000

本页描述了一些 Linux 内核中内置的、你可以在 Kubernetes 工作负载中使用的安全特性。要了解如何将这些特性应用到你的 Pod 和容器，请参阅为 Pod 或容器配置 SecurityContext。你须熟悉 Linux 和 Kubernetes 工作负载的基础知识。

API 发起的驱逐

Mon, 01 Jan 0001 00:00:00 +0000

API 发起的驱逐是一个先调用 Eviction API 创建 Eviction 对象，再由该对象体面地中止 Pod 的过程。

你可以通过直接调用 Eviction API 发起驱逐，也可以通过编程的方式使用 API 服务器的客户端来发起驱逐，比如 kubectl drain 命令。此操作创建一个 Eviction 对象，该对象再驱动 API 服务器终止选定的 Pod。

API 优先级和公平性

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.29 [stable]

对于集群管理员来说，控制 Kubernetes API 服务器在过载情况下的行为是一项关键任务。 kube-apiserver 有一些控件（例如：命令行标志 --max-requests-inflight 和 --max-mutating-requests-inflight），可以限制将要接受的未处理的请求，从而防止过量请求入站，潜在导致 API 服务器崩溃。但是这些标志不足以保证在高流量期间，最重要的请求仍能被服务器接受。

kubelet 认证/鉴权

Mon, 01 Jan 0001 00:00:00 +0000

概述

kubelet 的 HTTPS 端点公开了一些 API，这些 API 可以访问敏感度不同的数据，并允许你在节点上和容器内以不同级别的权限执行操作。

本文档介绍了如何对 kubelet 的 HTTPS 端点的访问进行认证和鉴权。

Kubernetes 云管理控制器

Mon, 01 Jan 0001 00:00:00 +0000

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

由于云驱动的开发和发布的步调与 Kubernetes 项目不同，将服务提供商专用代码抽象到 cloud-controller-manager 二进制中有助于云服务厂商在 Kubernetes 核心代码之外独立进行开发。

Linux 节点的交换（Swap）行为

Mon, 01 Jan 0001 00:00:00 +0000

要允许 Kubernetes 工作负载在 Linux 节点上使用交换分区，你必须禁用 kubelet 在检测到交换分区时失败的默认行为，并指定内存交换行为为 LimitedSwap：

可用的交换行为选项有：

NoSwap: （默认）在此节点上作为 Pod 运行的工作负载不会也不能使用交换分区。然而，系统守护进程（包括 kubelet 本身！）等这类 Kubernetes 范围之外的进程可以利用交换分区。这种行为有助于保护节点免受系统级别的内存峰值影响，但这不能保护工作负载本身不受此类峰值的影响。

LimitedSwap: Kubernetes 工作负载可以使用交换内存，Pod 可用的交换量是自动确定的。

要了解更多，请阅读交换内存管理。

Windows 存储

Mon, 01 Jan 0001 00:00:00 +0000

此页面提供特定于 Windows 操作系统的存储概述。

持久存储

Windows 有一个分层文件系统驱动程序用来挂载容器层和创建基于 NTFS 的文件系统拷贝。容器中的所有文件路径仅在该容器的上下文中解析。

Windows 网络

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 支持运行 Linux 或 Windows 节点。你可以在统一集群内混布这两种节点。本页提供了特定于 Windows 操作系统的网络概述。

Windows 容器网络

Windows 容器网络通过 CNI 插件暴露。 Windows 容器网络的工作方式与虚拟机类似。每个容器都有一个连接到 Hyper-V 虚拟交换机（vSwitch）的虚拟网络适配器（vNIC）。主机网络服务（Host Networking Service，HNS）和主机计算服务（Host Compute Service，HCS）协同创建容器并将容器 vNIC 挂接到网络。 HCS 负责管理容器，而 HNS 负责管理以下网络资源：

为 Pod 或容器配置安全上下文

Mon, 01 Jan 0001 00:00:00 +0000

安全上下文（Security Context）定义 Pod 或 Container 的特权与访问控制设置。安全上下文包括但不限于：

为应用程序设置干扰预算（Disruption Budget）

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.21 [stable]

本文展示如何限制应用程序的并发干扰数量，在允许集群管理员管理集群节点的同时保证高可用。

准备开始

你的 Kubernetes 服务器版本必须不低于版本 v1.21.

要获知版本信息，请输入 kubectl version.

你是 Kubernetes 集群中某应用的所有者，该应用有高可用要求。
你应了解如何部署无状态应用和/或有状态应用。
你应当已经阅读过关于 Pod 干扰的文档。
用户应当与集群所有者或服务提供者确认其遵从 Pod 干扰预算（Pod Disruption Budgets）的规则。

用 PodDisruptionBudget 来保护应用

确定想要使用 PodDisruptionBudget（PDB）来保护的应用。
考虑应用对干扰的反应。
以 YAML 文件形式定义 PDB。
通过 YAML 文件创建 PDB 对象。

确定要保护的应用

用户想要保护通过内置的 Kubernetes 控制器指定的应用，这是最常见的使用场景：

应用安全检查清单

Mon, 01 Jan 0001 00:00:00 +0000

本检查清单旨在为开发者提供在 Kubernetes 上安全地运行应用的基本指南。此列表并不打算详尽无遗，会随着时间的推移而不断演变。

关于如何阅读和使用本文档：

Service ClusterIP 分配

Mon, 01 Jan 0001 00:00:00 +0000

在 Kubernetes 中，Service 是一种抽象的方式，用于公开在一组 Pod 上运行的应用。 Service 可以具有集群作用域的虚拟 IP 地址（使用 type: ClusterIP 的 Service）。客户端可以使用该虚拟 IP 地址进行连接，Kubernetes 通过不同的后台 Pod 对该 Service 的流量进行负载均衡。

TLS 启动引导

Mon, 01 Jan 0001 00:00:00 +0000

在一个 Kubernetes 集群中，工作节点上的组件（kubelet 和 kube-proxy）需要与 Kubernetes 控制平面组件通信，尤其是 kube-apiserver。为了确保通信本身是私密的、不被干扰，并且确保集群的每个组件都在与另一个可信的组件通信，我们强烈建议使用节点上的客户端 TLS 证书。

安装扩展（Addon）

Mon, 01 Jan 0001 00:00:00 +0000

Add-on 扩展了 Kubernetes 的功能。

本文列举了一些可用的 add-on 以及到它们各自安装说明的链接。该列表并不试图详尽无遗。

联网和网络策略

ACI 通过 Cisco ACI 提供集成的容器网络和安全网络。
Antrea 在第 3/4 层执行操作，为 Kubernetes 提供网络连接和安全服务。Antrea 利用 Open vSwitch 作为网络的数据面。 Antrea 是一个沙箱级的 CNCF 项目。
Calico 是一个联网和网络策略供应商。 Calico 支持一套灵活的网络选项，因此你可以根据自己的情况选择最有效的选项，包括非覆盖和覆盖网络，带或不带 BGP。 Calico 使用相同的引擎为主机、Pod 和（如果使用 Istio 和 Envoy）应用程序在服务网格层执行网络策略。
Canal 结合 Flannel 和 Calico，提供联网和网络策略。
Cilium 是一种网络、可观察性和安全解决方案，具有基于 eBPF 的数据平面。 Cilium 提供了简单的 3 层扁平网络，能够以原生路由（routing）和覆盖/封装（overlay/encapsulation）模式跨越多个集群，并且可以使用与网络寻址分离的基于身份的安全模型在 L3 至 L7 上实施网络策略。 Cilium 可以作为 kube-proxy 的替代品；它还提供额外的、可选的可观察性和安全功能。 Cilium 是一个毕业级别的 CNCF 项目。

CNI-Genie 使 Kubernetes 无缝连接到 Calico、Canal、Flannel 或 Weave 等其中一种 CNI 插件。 CNI-Genie 是一个沙箱级的 CNCF 项目。
Contiv 为各种用例和丰富的策略框架提供可配置的网络（带 BGP 的原生 L3、带 vxlan 的覆盖、标准 L2 和 Cisco-SDN/ACI）。 Contiv 项目完全开源。其安装程序提供了基于 kubeadm 和非 kubeadm 的安装选项。
Contrail 基于 Tungsten Fabric，是一个开源的多云网络虚拟化和策略管理平台。 Contrail 和 Tungsten Fabric 与业务流程系统（例如 Kubernetes、OpenShift、OpenStack 和 Mesos）集成在一起，为虚拟机、容器或 Pod 以及裸机工作负载提供了隔离模式。

Flannel 是一个可以用于 Kubernetes 的 overlay 网络提供者。
Gateway API 是一个由 SIG Network 社区管理的开源项目，为服务网络建模提供一种富有表达力、可扩展和面向角色的 API。
Knitter 是在一个 Kubernetes Pod 中支持多个网络接口的插件。
Multus 是一个多插件，可在 Kubernetes 中提供多种网络支持，以支持所有 CNI 插件（例如 Calico、Cilium、Contiv、Flannel），而且包含了在 Kubernetes 中基于 SRIOV、DPDK、OVS-DPDK 和 VPP 的工作负载。

OVN-Kubernetes 是一个 Kubernetes 网络驱动，基于 OVN（Open Virtual Network）实现，是从 Open vSwitch (OVS) 项目衍生出来的虚拟网络实现。OVN-Kubernetes 为 Kubernetes 提供基于覆盖网络的网络实现，包括一个基于 OVS 实现的负载均衡器和网络策略。
Nodus 是一个基于 OVN 的 CNI 控制器插件，提供基于云原生的服务功能链 (SFC)。

NSX-T 容器插件（NCP）提供了 VMware NSX-T 与容器协调器（例如 Kubernetes）之间的集成，以及 NSX-T 与基于容器的 CaaS / PaaS 平台（例如关键容器服务（PKS）和 OpenShift）之间的集成。
Nuage 是一个 SDN 平台，可在 Kubernetes Pods 和非 Kubernetes 环境之间提供基于策略的联网，并具有可视化和安全监控。
Romana 是一个 Pod 网络的第三层解决方案，并支持 NetworkPolicy API。
Spiderpool 为 Kubernetes 提供了下层网络和 RDMA 高速网络解决方案，兼容裸金属、虚拟机和公有云等运行环境。
Terway 是一套基于阿里云 VPC 和 ECS 网络产品的 CNI 插件，能够在阿里云环境中提供原生的 VPC 网络和网络策略支持。
Weave Net 提供在网络分组两端参与工作的联网和网络策略，并且不需要额外的数据库。

服务发现

CoreDNS 是一种灵活的，可扩展的 DNS 服务器，可以安装为集群内的 Pod 提供 DNS 服务。

可视化管理

Dashboard 是一个 Kubernetes 的 Web 控制台界面。
Headlamp 是一个可扩展的 Kubernetes 用户界面（UI），既可以以集群内方式部署，也可以作为桌面应用程序使用。

基础设施

KubeVirt 是可以让 Kubernetes 运行虚拟机的 add-on。通常运行在裸机集群上。
节点问题检测器在 Linux 节点上运行，并将系统问题报告为事件或节点状况。

插桩

kube-state-metrics

遗留 Add-on

还有一些其它 add-on 归档在已废弃的 cluster/addons 路径中。

查看站点分析

Mon, 01 Jan 0001 00:00:00 +0000

此页面包含有关 kubernetes.io 分析仪表板的信息。

查看仪表板。

此仪表板使用 Google Looker Studio 构建，并显示自 2022 年 8 月以来使用 Google Analytics 4 在 kubernetes.io 上收集的信息。

从 Pod 中访问 Kubernetes API

Mon, 01 Jan 0001 00:00:00 +0000

本指南演示了如何从 Pod 中访问 Kubernetes API。

准备开始

定制 Hugo 短代码

Mon, 01 Jan 0001 00:00:00 +0000

本页面将介绍 Hugo 自定义短代码，可以用于 Kubernetes Markdown 文档书写。

关于短代码的更多信息可参见 Hugo 文档。

功能状态

在本站的 Markdown 页面（.md 文件）中，你可以加入短代码来展示所描述的功能特性的版本和状态。

服务内部流量策略

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.26 [stable]

服务内部流量策略开启了内部流量限制，将内部流量只路由到发起方所处节点内的服务端点。这里的”内部“流量指当前集群中的 Pod 所发起的流量。这种机制有助于节省开销，提升效率。

配置 kubelet 镜像凭据提供程序

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.26 [stable]

从 Kubernetes v1.20 开始，kubelet 可以使用 exec 插件动态获得针对某容器镜像库的凭据。 kubelet 使用 Kubernetes 版本化 API 通过标准输入输出（标准输入、标准输出和标准错误）和 exec 插件通信。这些插件允许 kubelet 动态请求容器仓库的凭据，而不是将静态凭据存储在磁盘上。例如，插件可能会与本地元数据服务器通信，以获得 kubelet 正在拉取的镜像的短期凭据。

同 Pod 内的容器使用共享卷通信

Mon, 01 Jan 0001 00:00:00 +0000

本文旨在说明如何让一个 Pod 内的两个容器使用一个卷（Volume）进行通信。参阅如何让两个进程跨容器通过共享进程名字空间。

准备开始

为 Kubernetes 组件和工具生成参考文档

Mon, 01 Jan 0001 00:00:00 +0000

本页面描述如何构造 Kubernetes 组件和工具的参考文档。

准备开始

阅读参考文档快速入门指南中的准备工作节。

按照参考文档快速入门指引，生成 Kubernetes 组件和工具的参考文档。

为 Pod 配置服务账号

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 提供两种完全不同的方式来为客户端提供支持，这些客户端可能运行在你的集群中，也可能与你的集群的控制面相关，需要向 API 服务器完成身份认证。

从私有仓库拉取镜像

Mon, 01 Jan 0001 00:00:00 +0000

本文介绍如何使用 Secret 从私有的镜像仓库或代码仓库拉取镜像来创建 Pod。有很多私有镜像仓库正在使用中。这个任务使用的镜像仓库是 Docker Hub。

流控

Mon, 01 Jan 0001 00:00:00 +0000

API 优先级和公平性控制着 Kubernetes API 服务器在负载过高的情况下的行为。你可以在 API 优先级和公平性文档中找到更多信息。

问题诊断

对于启用了 APF 的 API 服务器，每个 HTTP 响应都有两个额外的 HTTP 头： X-Kubernetes-PF-FlowSchema-UID 和 X-Kubernetes-PF-PriorityLevel-UID，给出与请求匹配的 FlowSchema 和已分配的优先级级别。如果请求用户没有查看这些对象的权限，则这些 HTTP 头中将不包含 API 对象的名称，因此在调试时，你可以使用类似如下的命令：

配置 API 对象配额

Mon, 01 Jan 0001 00:00:00 +0000

本文讨论如何为 API 对象配置配额，包括 PersistentVolumeClaim 和 Service。配额限制了可以在命名空间中创建的特定类型对象的数量。你可以在 ResourceQuota 对象中指定配额。

准备开始

为集群配置 DNS

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 提供 DNS 集群插件，大多数支持的环境默认情况下都会启用。在 Kubernetes 1.11 及其以后版本中，推荐使用 CoreDNS， kubeadm 默认会安装 CoreDNS。

要了解关于如何为 Kubernetes 集群配置 CoreDNS 的更多信息，参阅定制 DNS 服务。

访问集群上运行的服务

Mon, 01 Jan 0001 00:00:00 +0000

本文展示了如何连接 Kubernetes 集群上运行的服务。

准备开始

控制节点上的 CPU 管理策略

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.26 [stable]

按照设计，Kubernetes 对 Pod 执行相关的很多方面进行了抽象，使得用户不必关心。然而，为了正常运行，有些工作负载要求在延迟和/或性能方面有更强的保证。为此，kubelet 提供方法来实现更复杂的负载放置策略，同时保持抽象，避免显式的放置指令。

配置存活、就绪和启动探针

Mon, 01 Jan 0001 00:00:00 +0000

这篇文章介绍如何给容器配置存活（Liveness）、就绪（Readiness）和启动（Startup）探针。

更改 Kubernetes 软件包仓库

Mon, 01 Jan 0001 00:00:00 +0000

本页介绍了如何在升级集群时启用包含 Kubernetes 次要版本的软件包仓库。这仅适用于使用托管在 pkgs.k8s.io 上社区自治软件包仓库的用户。启用新的 Kubernetes 小版本的软件包仓库。与传统的软件包仓库不同，社区自治的软件包仓库所采用的结构为每个 Kubernetes 小版本都有一个专门的软件包仓库。

将 Pod 分配给节点

Mon, 01 Jan 0001 00:00:00 +0000

此页面显示如何将 Kubernetes Pod 指派给 Kubernetes 集群中的特定节点。

准备开始

控制节点上的拓扑管理策略

Mon, 01 Jan 0001 00:00:00 +0000

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

越来越多的系统利用 CPU 和硬件加速器的组合来支持要求低延迟的任务和高吞吐量的并行计算。这类负载包括电信、科学计算、机器学习、金融服务和数据分析等。此类混合系统需要有高性能环境支持。

用户命名空间

Mon, 01 Jan 0001 00:00:00 +0000

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

本页解释了在 Kubernetes Pod 中如何使用用户命名空间。用户命名空间将容器内运行的用户与主机中的用户隔离开来。

用节点亲和性把 Pod 分配到节点

Mon, 01 Jan 0001 00:00:00 +0000

本页展示在 Kubernetes 集群中，如何使用节点亲和性把 Kubernetes Pod 分配到特定节点。

准备开始

自定义 DNS 服务

Mon, 01 Jan 0001 00:00:00 +0000

本页说明如何配置 DNS Pod，以及定制集群中 DNS 解析过程。

准备开始

Downward API

Mon, 01 Jan 0001 00:00:00 +0000

对于容器来说，在不与 Kubernetes 过度耦合的情况下，拥有关于自身的信息有时是很有用的。 Downward API 允许容器在不使用 Kubernetes 客户端或 API 服务器的情况下获得自己或集群的信息。

调试 DNS 问题

Mon, 01 Jan 0001 00:00:00 +0000

这篇文章提供了一些关于 DNS 问题诊断的方法。

准备开始

配置 Pod 初始化

Mon, 01 Jan 0001 00:00:00 +0000

本文介绍在应用容器运行前，怎样利用 Init 容器初始化 Pod。

准备开始

声明网络策略

Mon, 01 Jan 0001 00:00:00 +0000

本文可以帮助你开始使用 Kubernetes 的 NetworkPolicy API 声明网络策略去管理 Pod 之间的通信

准备开始

为容器的生命周期事件设置处理函数

Mon, 01 Jan 0001 00:00:00 +0000

这个页面将演示如何为容器的生命周期事件挂接处理函数。Kubernetes 支持 postStart 和 preStop 事件。当一个容器启动后，Kubernetes 将立即发送 postStart 事件；在容器被终结之前， Kubernetes 将发送一个 preStop 事件。容器可以为每个事件指定一个处理程序。

开发云控制器管理器

Mon, 01 Jan 0001 00:00:00 +0000

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

一个 Kubernetes 控制平面组件，嵌入了特定于云平台的控制逻辑。云控制器管理器（Cloud Controller Manager）允许将你的集群连接到云提供商的 API 之上，并将与该云平台交互的组件同与你的集群交互的组件分离开来。

配置 Pod 使用 ConfigMap

Mon, 01 Jan 0001 00:00:00 +0000

很多应用在其初始化或运行期间要依赖一些配置信息。大多数时候，存在要调整配置参数所设置的数值的需求。 ConfigMap 是 Kubernetes 的一种机制，可让你将配置数据注入到应用的 Pod 内部。

启用/禁用 Kubernetes API

Mon, 01 Jan 0001 00:00:00 +0000

本页展示怎么用集群的控制平面. 启用/禁用 API 版本。

通过 API 服务器的命令行参数 --runtime-config=api/<version> ，可以开启/关闭某个指定的 API 版本。此参数的值是一个逗号分隔的 API 版本列表。此列表中，后面的值可以覆盖前面的值。

协调领导者选举

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.33 [beta]（默认禁用）

Kubernetes 1.35 包含一个 Beta 特性，允许控制平面组件通过协调领导者选举确定性地选择一个领导者。这对于在集群升级期间满足 Kubernetes 版本偏差约束非常有用。目前，唯一内置的选择策略是 OldestEmulationVersion，此策略会优先选择最低仿真版本作为领导者，其次按二进制版本选择领导者，最后会按创建时间戳选择领导者。

在 Pod 中的容器之间共享进程命名空间

Mon, 01 Jan 0001 00:00:00 +0000

此页面展示如何为 Pod 配置进程命名空间共享。当启用进程命名空间共享时，容器中的进程对同一 Pod 中的所有其他容器都是可见的。

你可以使用此功能来配置协作容器，比如日志处理 sidecar 容器，或者对那些不包含诸如 shell 等调试实用工具的镜像进行故障排查。

Pod 使用镜像卷

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.35 [beta]（默认启用）

本页展示了如何使用镜像卷配置 Pod。此特性允许你在容器内挂载来自 OCI 镜像仓库的内容。

准备开始

静态加密机密数据

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 中允许允许用户编辑的持久 API 资源数据的所有 API 都支持静态加密。例如，你可以启用静态加密 Secret。此静态加密是对 etcd 集群或运行 kube-apiserver 的主机上的文件系统的任何系统级加密的补充。

为 Pod 配置 user 名字空间

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.33 [beta]（默认启用）

本页展示如何为 Pod 配置 user 名字空间。可以将容器内的用户与主机上的用户隔离开来。

在容器中以 root 用户运行的进程可以以不同的（非 root）用户在宿主机上运行；换句话说，进程在 user 名字空间内部拥有执行操作的全部特权，但在 user 名字空间外部并没有执行操作的特权。

解密已静态加密的机密数据

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 中允许允许你写入持久性 API 资源数据的所有 API 都支持静态加密。例如，你可以为 Secret 启用静态加密。此静态加密是对 etcd 集群或运行 kube-apiserver 的主机上的文件系统的所有系统级加密的补充。

创建静态 Pod

Mon, 01 Jan 0001 00:00:00 +0000

静态 Pod 在指定的节点上由 kubelet 守护进程直接管理，不需要 API 服务器监管。与由控制面管理的 Pod（例如，Deployment）不同；kubelet 监视每个静态 Pod（在它失败之后重新启动）。

关键插件 Pod 的调度保证

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 核心组件（如 API 服务器、调度器、控制器管理器）在控制平面节点上运行。但是插件必须在常规集群节点上运行。其中一些插件对于功能完备的集群至关重要，例如 Heapster、DNS 和 UI。如果关键插件被逐出（手动或作为升级等其他操作的副作用）或者变成挂起状态，集群可能会停止正常工作。关键插件进入挂起状态的例子有：集群利用率过高；被逐出的关键插件 Pod 释放了空间，但该空间被之前悬决的 Pod 占用；由于其它原因导致节点上可用资源的总量发生变化。

混合版本代理

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.28 [alpha]（默认禁用）

Kubernetes 1.35 包含了一个 Alpha 特性，可以让 API 服务器代理指向其他对等 API 服务器的资源请求。它还允许客户通过发现功能全面了解整个集群提供的资源。当一个集群中运行着多个 API 服务器，且各服务器的 Kubernetes 版本不同时（例如在上线 Kubernetes 新版本的时间跨度较长时），这一特性非常有用。

IP Masquerade Agent 用户指南

Mon, 01 Jan 0001 00:00:00 +0000

此页面展示如何配置和启用 ip-masq-agent。

准备开始

将 Docker Compose 文件转换为 Kubernetes 资源

Mon, 01 Jan 0001 00:00:00 +0000

Kompose 是什么？它是一个转换工具，可将 Compose （即 Docker Compose）所组装的所有内容转换成容器编排器（Kubernetes 或 OpenShift）可识别的形式。

更多信息请参考 Kompose 官网 https://kompose.io/。

准备开始

通过配置内置准入控制器实施 Pod 安全标准

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 提供一种内置的准入控制器用来强制实施 Pod 安全性标准。你可以配置此准入控制器来设置集群范围的默认值和豁免选项。

准备开始

Pod 安全性准入（Pod Security Admission）在 Kubernetes v1.22 作为 Alpha 特性发布，在 Kubernetes v1.23 中作为 Beta 特性默认可用。从 1.25 版本起，此特性进阶至正式发布（Generally Available）。

限制存储使用量

Mon, 01 Jan 0001 00:00:00 +0000

此示例演示如何限制一个名字空间中的存储使用量。

演示中用到了以下资源：ResourceQuota、 LimitRange 和 PersistentVolumeClaim。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

迁移多副本的控制面以使用云控制器管理器

Mon, 01 Jan 0001 00:00:00 +0000

使用名字空间标签来实施 Pod 安全性标准

Mon, 01 Jan 0001 00:00:00 +0000

名字空间可以打上标签以强制执行 Pod 安全性标准。特权（privileged）、基线（baseline）和受限（restricted）这三种策略涵盖了广泛安全范围，并由 Pod 安全准入控制器实现。

准备开始

Pod 安全性准入（Pod Security Admission）在 Kubernetes v1.23 中作为 Beta 特性默认可用。从 1.25 版本起，此特性进阶至正式发布（Generally Available）。

从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器

Mon, 01 Jan 0001 00:00:00 +0000

本页面描述从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器的过程。这一迁移过程可以通过综合使用试运行、audit 和 warn 模式等来实现，尽管在使用了变更式 PSP 时会变得有些困难。

名字空间演练

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 名字空间有助于不同的项目、团队或客户去共享 Kubernetes 集群。

名字空间通过以下方式实现这点：

操作 Kubernetes 中的 etcd 集群

Mon, 01 Jan 0001 00:00:00 +0000

etcd 是一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。

为系统守护进程预留计算资源

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 的节点可以按照 Capacity 调度。默认情况下 pod 能够使用节点全部可用容量。这是个问题，因为节点自己通常运行了不少驱动 OS 和 Kubernetes 的系统守护进程。除非为这些系统守护进程留出资源，否则它们将与 Pod 争夺资源并导致节点资源短缺问题。

以非 root 用户身份运行 Kubernetes 节点组件

Mon, 01 Jan 0001 00:00:00 +0000

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

本页展示了如何在确保 PodDisruptionBudget 的前提下，安全地清空一个节点。

准备开始

此任务假定你已经满足了以下先决条件：

保护集群

Mon, 01 Jan 0001 00:00:00 +0000

本文档涉及与保护集群免受意外或恶意访问有关的主题，并对总体安全性提出建议。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

通过配置文件设置 kubelet 参数

Mon, 01 Jan 0001 00:00:00 +0000

准备开始

此页面中的某些步骤使用 jq 工具。如果你没有 jq，你可以通过操作系统的软件源安装它，或者从 https://jqlang.github.io/jq/ 中获取它。

通过名字空间共享集群

Mon, 01 Jan 0001 00:00:00 +0000

本页展示如何查看、使用和删除名字空间。本页同时展示如何使用 Kubernetes 名字空间来划分集群。

准备开始

你已拥有一个配置好的 Kubernetes 集群。
你已对 Kubernetes 的 Pod、 Service 和 Deployment 有基本理解。

查看名字空间

列出集群中现有的名字空间：

升级集群

Mon, 01 Jan 0001 00:00:00 +0000

本页概述升级 Kubernetes 集群的步骤。

在集群中使用级联删除

Mon, 01 Jan 0001 00:00:00 +0000

本页面向你展示如何设置在你的集群执行垃圾收集时要使用的级联删除类型。

准备开始

使用 KMS 驱动进行数据加密

Mon, 01 Jan 0001 00:00:00 +0000

本页展示了如何配置密钥管理服务（Key Management Service，KMS）驱动和插件以启用 Secret 数据加密。在 Kubernetes 1.35 中，存在两个版本的 KMS 静态加密方式。如果可行的话，建议使用 KMS v2，因为（自 Kubernetes v1.28 起）KMS v1 已经被弃用并（自 Kubernetes v1.29 起）默认被禁用。 KMS v2 提供了比 KMS v1 明显更好的性能特征。

使用 CoreDNS 进行服务发现

Mon, 01 Jan 0001 00:00:00 +0000

此页面介绍了 CoreDNS 升级过程以及如何安装 CoreDNS 而不是 kube-dns。

准备开始

在 Kubernetes 集群中使用 NodeLocal DNSCache

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.18 [stable]

本页概述了 Kubernetes 中的 NodeLocal DNSCache 功能。

准备开始

在 Kubernetes 集群中使用 sysctl

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.21 [stable]

本文档介绍如何通过 sysctl 接口在 Kubernetes 集群中配置和使用内核参数。

说明：

从 Kubernetes 1.23 版本开始，kubelet 支持使用 / 或 . 作为 sysctl 参数的分隔符。从 Kubernetes 1.25 版本开始，支持为 Pod 设置 sysctl 时使用设置名字带有斜线的 sysctl。例如，你可以使用点或者斜线作为分隔符表示相同的 sysctl 参数，以点作为分隔符表示为： kernel.shm_rmid_forced，或者以斜线作为分隔符表示为：kernel/shm_rmid_forced。更多 sysctl 参数转换方法详情请参考 Linux man-pages sysctl.d(5)。

使用 NUMA 感知的内存管理器

Mon, 01 Jan 0001 00:00:00 +0000

特性状态： Kubernetes v1.32 [stable]（默认启用）

Kubernetes 内存管理器（Memory Manager）为 Guaranteed QoS 类的 Pods 提供可保证的内存（及大页面）分配能力。

验证已签名容器镜像

Mon, 01 Jan 0001 00:00:00 +0000

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

准备开始

你需要安装以下工具：

cosign（安装指南)
curl（通常由你的操作系统提供）
jq（下载 jq）

验证二进制签名

Kubernetes 发布过程使用 cosign 的无密钥签名对所有二进制工件（压缩包、 SPDX 文件、独立的二进制文件）签名。要验证一个特定的二进制文件，获取组件时要包含其签名和证书：

Headlamp 2025 年度项目亮点

Thu, 22 Jan 2026 10:00:00 +0800

本公告是对最初在 Headlamp 博客上发布的帖子的回顾。

Headlamp 在 2025 年取得了长足的发展。该项目持续成长，覆盖了更多平台和团队；通过插件机制支持了新的工作流和集成方式；同时也看到了来自更广泛社区的协作不断增强。

Kubernetes v1.35：云控制器管理器中的基于监视的路由协调

Thu, 08 Jan 2026 10:30:00 -0800

在 Kubernetes v1.34 及更早版本中，使用 k8s.io/cloud-provider 库构建的云控制器管理器（CCM）实现中的路由控制器会以固定的时间间隔进行路由协调。这会导致在路由没有变化的情况下，向云提供商发出不必要的 API 请求。其他使用同一库实现的控制器已经使用基于监听的机制，利用 informer 来避免不必要的 API 调用。 v1.35 版本引入了一个新的特性门控，允许更改路由控制器的行为，使其使用基于监听的 informer。

Kubernetes v1.35: 通过就地重启 Pod 实现更高的效率

Mon, 05 Jan 2026 10:30:00 -0800

Kubernetes 1.35 版本引入了一项强大的新特性，满足了用户对 Pod 就地重启的迫切需求。这项名为“重启所有容器”（Restart All Containers，1.35 版本为 Alpha 版）的特性，相比于资源用量较高的删除并重建整个 Pod 的方式，能够更高效地重置 Pod 的状态。该特性对于 AI/ML 工作负载尤为实用，使应用程序开发人员能够专注于核心训练逻辑，同时将复杂的故障处理和恢复机制交给边车容器和声明式 Kubernetes 配置来处理。凭借 RestartAllContainers 和其他计划中的增强特性， Kubernetes 将继续构建更灵活、更健壮、更高效的 AI/ML 工作负载平台。

Kubernetes v1.35：扩展容忍度运算符以支持数值比较（Alpha）

Mon, 05 Jan 2026 10:30:00 -0800

许多生产级 Kubernetes 集群会混合使用按需（on-demand，高 SLA）节点与 spot/可抢占（preemptible，低 SLA）节点，以在保证关键工作负载可靠性的同时优化成本。平台团队需要一个“安全默认值”，让大多数工作负载远离风险容量，同时又允许特定工作负载用明确阈值显式选择接受（opt-in），例如“我可以容忍失败概率最高 5% 的节点”。

Kubernetes v1.35：Job Managed By 特性正式发布（GA）

Thu, 18 Dec 2025 10:30:00 -0800

在 Kubernetes v1.35 中，通过 .spec.managedBy 指定外部 Job 控制器的能力升级为正式可用（GA）。

该特性允许外部控制器对 Job 的调谐（reconciliation）承担完全责任，从而解锁更强大的调度模式，例如借助 MultiKueue 进行跨多集群派发。

Kubernetes v1.35：Timbernetes（世界树版本）

Wed, 17 Dec 2025 10:30:00 -0800

编辑：Aakanksha Bhende、Arujjwal Negi、Chad M. Crowell、Graziano Casto、Swathi Rao

与之前版本类似，Kubernetes v1.35 的发布引入了新的稳定（GA）、Beta 和 Alpha 特性。持续交付高质量版本，体现了我们开发周期的韧性，也离不开社区的热情支持。

Kubernetes v1.35 抢先一览

Wed, 26 Nov 2025 00:00:00 +0000

随着 Kubernetes v1.35 发布的临近，Kubernetes 项目持续演进。为了改善项目的整体健康状况，某些功能可能会被弃用、移除或替换。本博客文章概述了 v1.35 版本的计划变更，发布团队认为你应该了解这些变更，以确保 Kubernetes 集群的持续平稳运行，并让你了解最新进展。以下信息基于 v1.35 版本的当前状态，在最终发布日期之前可能会发生变化。

Kubernetes 配置最佳实践

Tue, 25 Nov 2025 00:00:00 +0000

配置是 Kubernetes 中看似微不足道，实则关键的事情之一。配置是每个 Kubernetes 工作负载的核心。一个缺失的引号、错误的 API 版本或错位的 YAML 缩进都可能毁掉你的整个部署。

Ingress NGINX 退役：你需要了解的内容

Tue, 11 Nov 2025 10:30:00 -0800

为了优先考虑生态系统的安全，Kubernetes SIG Network 和安全响应委员会宣布 Ingress NGINX 即将退役，并将尽力将其维护期持续到 2026 年 3 月。之后，将不再有进一步的版本发布、错误修复和更新来解决可能发现的任何安全漏洞。 现有的 Ingress NGINX Deployment 将继续运行，并且安装工件仍将可用。

公布 2025 年指导委员会选举结果

Sun, 09 Nov 2025 15:10:00 -0500

2025 指导委员会选举现已结束。 Kubernetes 指导委员会由 7 个席位组成，其中 4 个席位在 2025 年进行了选举。新当选的委员会成员将任职 2 年，所有成员均由 Kubernetes 社区选举产生。

7 个常见的 Kubernetes 坑（以及我是如何避开的）

Mon, 20 Oct 2025 08:30:00 -0700

Kubernetes 功能强大，但有时也会令人沮丧，这已不是什么秘密。当我刚开始接触容器编排时，我犯了不少错误，足以列出一整张误区清单。在这篇文章中，我想分享我遇到的（或看到其他人遇到的）七个常见误区，以及如何避免它们的建议。无论你只是刚开始尝试 Kubernetes，还是已经在管理生产集群，我希望这些见解能帮助你避免一些额外的麻烦。

Kubernetes v1.34：从存储卷扩展失效中恢复（GA）

Fri, 19 Sep 2025 10:30:00 -0800

你是否曾经在扩展 Kubernetes 中的持久卷时犯过拼写错误？本来想指定 2TB 却写成了 20TiB？这个看似无害的问题实际上很难修复——项目花了将近 5 年时间才解决。存储扩展的自动恢复此特性在一段时间内一直处于 Beta 状态；不过，随着 v1.34 版本的发布，我们已经将其提升到正式发布状态。

Kubernetes v1.34: 将卷组快照推进至 v1beta2 阶段

Tue, 16 Sep 2025 10:30:00 -0800

卷组快照在 Kubernetes 1.27 版本中作为 Alpha 特性被引入，并在 Kubernetes 1.32 版本中移至 Beta 阶段。 Kubernetes v1.34 的最近一次发布将该支持移至第二个 Beta 阶段。对卷组快照的支持依赖于一组用于组快照的扩展 API。这些 API 允许用户为一组卷获取崩溃一致性快照。在后台，Kubernetes 根据标签选择器对多个 PersistentVolumeClaim 分组，并进行快照操作。关键目标是允许你将这组快照恢复到新卷上，并基于崩溃一致性恢复点恢复工作负载。

Kubernetes v1.34：可变 CSI 节点可分配数进阶至 Beta

Thu, 11 Sep 2025 10:30:00 -0800

CSI 驱动更新节点上可挂接卷数量信息的这一功能在 Kubernetes v1.33 中首次以 Alpha 引入，如今在 Kubernetes v1.34 中进阶为 Beta！这是提升有状态 Pod 调度准确性的重要里程碑，可减少因可挂接卷容量信息过时所导致的调度失败问题。

Kubernetes v1.34: 使用 Init 容器定义应用环境变量

Wed, 10 Sep 2025 10:30:00 -0800

Kubernetes 通常使用 ConfigMap 和 Secret 来设置环境变量，这会引入额外的 API 调用和复杂性。例如，你需要分别管理工作负载的 Pod 和它们的配置，同时还要确保配置和工作负载 Pod 的有序更新。

Kubernetes v1.34: Kubernetes 中的 PSI 指标进入 Beta 阶段

Thu, 04 Sep 2025 10:30:00 -0800

随着 Kubernetes 集群规模和复杂性的增长，了解各个节点的健康状况和性能变得越来越关键。我们很高兴地宣布，从 Kubernetes v1.34 开始，压力停滞信息 (PSI) 指标已升级到 Beta 版本。

Headlamp AI 助手简介

Thu, 07 Aug 2025 20:00:00 +0100

本文是 Headlamp AI 助手介绍这篇博客的中文译稿。

为了简化 Kubernetes 的管理和故障排除，我们非常高兴地推出 Headlamp AI 助手：这是 Headlamp 的一个强大的新插件，可以帮助你更清晰、更轻松地理解和操作你的 Kubernetes 集群和应用程序。

Kubernetes v1.34 抢先一览

Mon, 28 Jul 2025 00:00:00 +0000

Kubernetes v1.34 将于 2025 年 8 月底发布。本次发版不会移除或弃用任何特性，但包含了数量惊人的增强特性。以下列出一些本次发版最令人兴奋的特性！

云原生环境中的镜像兼容性

Wed, 25 Jun 2025 00:00:00 +0000

在电信、高性能或 AI 计算等必须高度可靠且满足严格性能标准的行业中，容器化应用通常需要特定的操作系统配置或硬件支持。通常的做法是要求使用特定版本的内核、其配置、设备驱动程序或系统组件。尽管存在开放容器倡议 (OCI) 这样一个定义容器镜像标准和规范的治理社区，但在表达这种兼容性需求方面仍存在空白。为了解决这一问题，业界提出了多个提案，并最终在 Kubernetes 的节点特性发现 (NFD) 项目中实现了相关功能。

Kubernetes Slack 变更公告

Mon, 16 Jun 2025 00:00:00 +0000

更新：我们已收到 Salesforce 的通知，我们的 Slack 工作区在 6 月 20 日不会被降级。请等待更多细节更新，目前无需紧急备份私有频道或私信。

~~Kubernetes Slack 将在 6 月 20 日失去原有的专属支持，并转变为标准免费版 Slack~~~。今年晚些时候，我们的社区可能会迁移到新平台。如果你是频道或私有频道的负责人，又或是用户组的成员，你需要尽快采取一些行动。

通过自定义聚合增强 Kubernetes Event 管理

Tue, 10 Jun 2025 00:00:00 +0000

Kubernetes Event 提供了集群操作的关键洞察信息，但随着集群的增长，管理和分析这些 Event 变得越来越具有挑战性。这篇博客文章探讨了如何构建自定义 Event 聚合系统，以帮助工程团队更好地理解集群行为并更有效地解决问题。

介绍 Gateway API 推理扩展

Thu, 05 Jun 2025 00:00:00 +0000

现代生成式 AI 和大语言模型（LLM）服务在 Kubernetes 上带来独特的流量路由挑战。与典型的短生命期的无状态 Web 请求不同，LLM 推理会话通常是长时间运行的、资源密集型的，并且具有一定的状态性。例如，单个由 GPU 支撑的模型服务器可能会保持多个推理会话处于活跃状态，并保留内存中的令牌缓存。

先启动边车：如何避免障碍

Tue, 03 Jun 2025 00:00:00 +0000

从 "Kubernetes 多容器 Pod：概述"博客中，你了解了 Pod 的工作方式，Pod 的主要架构模式，以及 Pod 在 Kubernetes 中是如何实现的。本文主要介绍的是如何确保你的边车容器在主应用之前启动。这比你想象的要复杂得多！

Gateway API v1.3.0：流量复制、CORS、Gateway 合并和重试预算的改进

Mon, 02 Jun 2025 09:00:00 -0800

加入 Kubernetes SIG Network 社区，共同庆祝 Gateway API v1.3.0 正式发布！我们很高兴地宣布，通过推迟这篇博客的发布，现在已经有了多个符合规范的实现可供试用。 API 1.3.0 版本已于 2025 年 4 月 24 日发布。

Kubernetes v1.33：原地调整 Pod 资源特性升级为 Beta

Fri, 16 May 2025 10:30:00 -0800

代表 Kubernetes 项目，我很高兴地宣布，原地 Pod 调整大小特性（也称为原地 Pod 垂直缩放），在 Kubernetes v1.27 中首次引入为 Alpha 版本，现在已升级为 Beta 版本，并将在 Kubernetes v1.33 发行版中默认启用！这标志着 Kubernetes 工作负载的资源管理变得更加灵活和不那么具有干扰性的一个重要里程碑。

Kubernetes 1.33：Job 的 SuccessPolicy 进阶至 GA

Thu, 15 May 2025 10:30:00 -0800

我代表 Kubernetes 项目组，很高兴地宣布在 v1.33 版本中，Job 的成功策略已进阶至 GA（正式发布）。

关于 Job 的成功策略

在批处理工作负载中，你可能希望使用类似 MPI（消息传递接口）的领导者跟随者（leader-follower）模式，其中领导者控制执行过程，包括跟随者的生命周期。

Kubernetes v1.33：容器生命周期更新

Wed, 14 May 2025 10:30:00 -0800

Kubernetes v1.33 引入了对容器生命周期的一些更新。容器生命周期回调的 Sleep 动作现在支持零睡眠时长（特性默认启用）。同时还为定制发送给终止中的容器的停止信号提供了 Alpha 级别支持。

Kubernetes v1.33：Job 逐索引的回退限制进阶至 GA

Tue, 13 May 2025 10:30:00 -0800

在 Kubernetes v1.33 中，逐索引的回退限制特性进阶至 GA（正式发布）。本文介绍此特性及其优势。

关于逐索引的回退限制

当你在 Kubernetes 上运行工作负载时，必须考虑 Pod 失效可能影响工作负载完成的场景。理想情况下，你的工作负载应该能够容忍短暂的失效并继续运行。

Kubernetes v1.33：镜像拉取策略终于按你的预期工作了！

Mon, 12 May 2025 10:30:00 -0800

镜像拉取策略终于按你的预期工作了！

Kubernetes 中有些东西让人感到奇怪，imagePullPolicy 的行为就是其中之一。 Kubernetes 作为一个专注于运行 Pod 的平台，居然在限制 Pod 访问经认证的镜像方面，存在一个长达十余年的问题，详见 Issue 18787！ v1.33 解决了这个十年前的老问题，这真是一个有纪念意义的版本。

Kubernetes v1.33：流式 List 响应

Fri, 09 May 2025 10:30:00 -0800

随着基础设施的增长，管理 Kubernetes 集群的稳定性变得愈发重要。在大规模集群的运维中，最具挑战性的操作之一就是处理获取大量数据集的 List 请求。 List 请求是一种常见的操作，却可能意外影响集群的稳定性。

Kubernetes 1.33：卷填充器进阶至 GA

Thu, 08 May 2025 10:30:00 -0800

Kubernetes 的卷填充器现已进阶至 GA（正式发布）！ AnyVolumeDataSource 特性门控在 Kubernetes v1.33 中设为始终启用，这意味着用户可以将任何合适的自定义资源作为 PersistentVolumeClaim（PVC）的数据源。

Kubernetes v1.33：防止无序删除时 PersistentVolume 泄漏特性进阶到 GA

Mon, 05 May 2025 10:30:00 -0800

我很高兴地宣布，当无序删除时防止 PersistentVolume（简称 PV）泄漏的特性已经在 Kubernetes v1.33 中进阶为正式版（GA）！这项改进最初在 Kubernetes v1.31 中作为 Beta 特性引入，确保你的存储资源能够被正确回收，防止不必要的泄漏。

Kubernetes v1.33：可变的 CSI 节点可分配数

Fri, 02 May 2025 10:30:00 -0800

可靠调度有状态应用极度依赖于节点上资源可用性的准确信息。
Kubernetes v1.33 引入一个名为可变的 CSI 节点可分配计数的 Alpha 特性，允许 CSI（容器存储接口）驱动动态更新节点可以处理的最大卷数量。
这一能力显著提升 Pod 调度决策的准确性，并减少因卷容量信息过时而导致的调度失败。

Kubernetes v1.33：存储动态制备模式下的节点存储容量评分（Alpha 版）

Wed, 30 Apr 2025 10:30:00 -0800

Kubernetes v1.33 引入了一个名为 StorageCapacityScoring 的新 Alpha 级别特性。此特性添加了一种为 Pod 调度评分的方法，并与拓扑感知卷制备相关。此特性可以轻松地选择在具有最多或最少可用存储容量的节点上调度 Pod。

Kubernetes v1.33：镜像卷进阶至 Beta！

Tue, 29 Apr 2025 10:30:00 -0800

镜像卷作为 Alpha 特性首次引入 Kubernetes v1.31 版本，并作为 KEP-4639 的一部分发布。在 Kubernetes v1.33 中，此特性进阶至 Beta。

请注意，此特性目前仍默认禁用，因为并非所有的容器运行时都完全支持此特性。 CRI-O 自 v1.31 起就支持此初始特性，并将在 v1.33 中添加对镜像卷的 Beta 支持。 containerd 已合并对 Alpha 特性的支持，此特性将包含在 containerd v2.1.0 版本中，并正通过 PR #11578 实现对 Beta 的支持。

Kubernetes v1.33：HorizontalPodAutoscaler 可配置容差

Mon, 28 Apr 2025 10:30:00 -0800

这篇文章描述了水平 Pod 自动扩缩的可配置容差，这是在 Kubernetes 1.33 中首次出现的一个新的 Alpha 特性。

它是什么？

水平 Pod 自动扩缩是 Kubernetes 中一个众所周知的特性，它允许你的工作负载根据资源利用率自动增减副本数量。

Kubernetes 多容器 Pod：概述

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

随着云原生架构的不断演进，Kubernetes 已成为部署复杂分布式系统的首选平台。在这个生态系统中，最强大却又微妙的设计模式之一是边车（Sidecar）模式 —— 一种允许开发者扩展应用功能而不深入源代码的技术。

kube-scheduler-simulator 介绍

Mon, 07 Apr 2025 00:00:00 +0000

Kubernetes 调度器（Scheduler）是一个关键的控制平面组件，负责决定 Pod 将运行在哪个节点上。
因此，任何使用 Kubernetes 的人都依赖于调度器。

Kubernetes v1.33 预览

Wed, 26 Mar 2025 10:30:00 -0800

随着 Kubernetes v1.33 版本的发布临近，Kubernetes 项目仍在不断发展。为了提升项目的整体健康状况，某些特性可能会被弃用、移除或替换。这篇博客文章概述了 v1.33 版本的一些计划变更，发布团队认为你有必要了解这些内容，以确保 Kubernetes 环境的持续平稳运行，并让你掌握最新的发展动态。以下信息基于 v1.33 版本的当前状态，在最终发布日期之前可能会有所变化。

ingress-nginx CVE-2025-1974 须知

Mon, 24 Mar 2025 12:00:00 -0800

今天，ingress-nginx 项目的维护者们发布了一批关键漏洞的修复补丁，这些漏洞可能让攻击者轻易接管你的 Kubernetes 集群。目前有 40% 以上的 Kubernetes 管理员正在使用 ingress-nginx，如果你是其中之一，请立即采取行动，保护你的用户和数据。

JobSet 介绍

Sun, 23 Mar 2025 00:00:00 +0000

在本文中，我们介绍 JobSet，这是一个用于表示分布式任务的开源 API。 JobSet 的目标是为 Kubernetes 上的分布式机器学习训练和高性能计算（HPC）工作负载提供统一的 API。

为什么需要 JobSet？

Kubernetes 社区近期对 Kubernetes 批处理生态系统的增强，吸引了许多机器学习工程师，他们发现这非常符合运行分布式训练工作负载的需求。

聚焦 SIG Apps

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

在我们正在进行的 SIG 聚焦系列中，我们通过与 Kubernetes 项目各个特别兴趣小组（SIG）的领导者对话，深入探讨 Kubernetes 项目的核心。这一次，我们聚焦于 SIG Apps，这个小组负责 Kubernetes 上与应用程序开发、部署和操作相关的所有内容。 Sandipan Panda（[DevZero](https://www.devzero.io/））有机会采访了 SIG Apps 的主席和技术负责人 Maciej Szulik（Defense Unicorns）以及 Janet Kuo（Google）。他们分享了在 Kubernetes 生态系统中关于应用管理的经验、挑战以及未来愿景。

kube-proxy 的 NFTables 模式

Fri, 28 Feb 2025 00:00:00 +0000

Kubernetes 1.29 引入了一种新的 Alpha 特性：kube-proxy 的 nftables 模式。目前该模式处于 Beta 阶段，并预计将在 1.33 版本中达到一般可用（GA）状态。新模式解决了 iptables 模式长期存在的性能问题，建议所有运行在较新内核版本系统上的用户尝试使用。出于兼容性原因，即使 nftables 成为 GA 功能，iptables 仍将是默认模式。

云控制器管理器（Cloud Controller Manager）'鸡与蛋'的问题

Fri, 14 Feb 2025 00:00:00 +0000

Kubernetes 1.31
完成了 Kubernetes 历史上最大的迁移，移除了树内云驱动（in-tree cloud provider）。虽然组件迁移已经完成，但这为用户和安装项目（例如 kOps 或 Cluster API）带来了一些额外的复杂性。我们将回顾这些额外的步骤和可能的故障点，并为集群所有者提供改进建议。
此次迁移非常复杂，必须从核心组件中提取部分逻辑，构建四个新的子系统。

聚焦 SIG Architecture: Enhancements

Tue, 21 Jan 2025 00:00:00 +0000

这是 SIG Architecture 聚光灯系列的第四次采访，我们将介绍 SIG Architecture: Enhancements。

在本次 SIG Architecture 专题采访中，我们访谈了 Enhancements 子项目的负责人 Kirsten Garrison。

使用 API 流式传输来增强 Kubernetes API 服务器效率

Tue, 17 Dec 2024 00:00:00 +0000

高效管理 Kubernetes 集群至关重要，特别是在集群规模不断增长的情况下更是如此。大型集群面临的一个重大挑战是 list 请求所造成的内存开销。

在现有的实现中，kube-apiserver 在处理 list 请求时，先在内存中组装整个响应，再将所有数据传输给客户端。但如果响应体非常庞大，比如数百兆字节呢？另外再想象这样一种场景，有多个 list 请求同时涌入，可能是在短暂的网络中断后涌入。虽然 API 优先级和公平性已经证明可以合理地保护 kube-apiserver 免受 CPU 过载，但其对内存保护的影响却明显较弱。这可以解释为各个 API 请求的资源消耗性质有所不同。在任何给定时间，CPU 使用量都会受到某个常量的限制，而内存由于不可压缩，会随着处理对象数量的增加而成比例增长，且没有上限。这种情况会带来真正的风险，kube-apiserver 可能会在几秒钟内因内存不足（OOM）状况而淹没和崩溃。为了更直观地查验这个问题，我们看看下面的图表。

Kubernetes v1.32 增加了新的 CPU Manager 静态策略选项用于严格 CPU 预留

Mon, 16 Dec 2024 00:00:00 +0000

在 Kubernetes v1.32 中，经过社区多年的讨论，我们很高兴地引入了 CPU Manager 静态策略的 strict-cpu-reservation 选项。此特性当前处于 Alpha 阶段，默认情况下关联的策略是隐藏的。只有在你的集群中明确启用了此 Alpha 行为后，才能使用此策略。

Kubernetes v1.32：内存管理器进阶至 GA

Fri, 13 Dec 2024 00:00:00 +0000

随着 Kubernetes 1.32 的发布，内存管理器已进阶至正式发布（GA），这标志着在为容器化应用实现高效和可预测的内存分配的旅程中迈出了重要的一步。内存管理器自 Kubernetes v1.22 进阶至 Beta 后，其可靠性、稳定性已得到证实，是 CPU 管理器的一个良好补充特性。

Kubernetes v1.32：QueueingHint 为优化 Pod 调度带来了新的可能

Thu, 12 Dec 2024 00:00:00 +0000

Kubernetes 调度器是为新 Pod 选择运行节点的核心组件，调度器会逐一处理这些新 Pod。因此，集群规模越大，调度器的吞吐量就越重要。

Kubernetes v1.32 预览

Fri, 08 Nov 2024 00:00:00 +0000

随着 Kubernetes v1.32 发布日期的临近，Kubernetes 项目继续发展和成熟。在这个过程中，某些特性可能会被弃用、移除或被更好的特性取代，以确保项目的整体健康与发展。

关于日本的 Kubernetes 上游培训的特别报道

Mon, 28 Oct 2024 00:00:00 +0000

我们是日本 Kubernetes 上游培训的组织者。我们的团队由积极向 Kubernetes 做贡献的成员组成，他们在社区中担任了 Member、Reviewer、Approver 和 Chair 等角色。

公布 2024 年指导委员会选举结果

Wed, 02 Oct 2024 15:10:00 -0500

2024 年指导委员会选举现已完成。 Kubernetes 指导委员会由 7 个席位组成，其中 3 个席位于 2024 年进行选举。新任委员会成员的任期为 2 年，所有成员均由 Kubernetes 社区选举产生。

SIG Scheduling 访谈

Tue, 24 Sep 2024 00:00:00 +0000

在本次 SIG Scheduling 的访谈中，我们与 Kensei Nakada 进行了交流，他是 SIG Scheduling 的一名 Approver。

Kubernetes v1.31：kubeadm v1beta4

Fri, 23 Aug 2024 00:00:00 +0000

作为 Kubernetes v1.31 发布的一部分，kubeadm 采用了全新版本（v1beta4）的配置文件格式。之前 v1beta3 格式的配置现已正式弃用，这意味着尽管之前的格式仍然受支持，但你应迁移到 v1beta4 并停止使用已弃用的格式。对 v1beta3 配置的支持将在至少 3 次 Kubernetes 次要版本发布后被移除。

Kubernetes 1.31：kubectl debug 中的自定义模板化配置特性已进入 Beta 阶段

Thu, 22 Aug 2024 00:00:00 +0000

有很多方法可以对集群中的 Pod 和节点进行故障排查，而 kubectl debug 是最简单、使用最广泛、最突出的方法之一。它提供了一组静态配置，每个配置适用于不同类型的角色。例如，从网络管理员的视角来看，调试节点应该像这样简单：

Kubernetes 1.31：细粒度的 SupplementalGroups 控制

Thu, 22 Aug 2024 00:00:00 +0000

本博客讨论了 Kubernetes 1.31 中的一项新特性，目的是改善处理 Pod 中容器内的附加组。

动机：容器镜像中 `/etc/group` 中定义的隐式组成员关系

尽管这种行为可能并不受许多 Kubernetes 集群用户/管理员的欢迎，但 Kubernetes 默认情况下会将 Pod 中的组信息与容器镜像中 /etc/group 中定义的信息进行合并。

Kubernetes v1.31：全新的 Kubernetes CPUManager 静态策略：跨核分发 CPU

Thu, 22 Aug 2024 00:00:00 +0000

在 Kubernetes v1.31 中，我们很高兴引入了对 CPU 管理能力的重大增强：针对 CPUManager 静态策略的 distribute-cpus-across-cores 选项。此特性目前处于 Alpha 阶段，默认被隐藏，标志着旨在优化 CPU 利用率和改善多核处理器系统性能的战略转变。

Kubernetes 1.31: 节点 Cgroup 驱动程序的自动配置 (beta)

Wed, 21 Aug 2024 00:00:00 +0000

一直以来，为新运行的 Kubernetes 集群配置正确的 cgroup 驱动程序是用户的一个痛点。在 Linux 系统中，存在两种不同的 cgroup 驱动程序：cgroupfs 和 systemd。过去，kubelet 和 CRI 实现（如 CRI-O 或 containerd）需要配置为使用相同的 cgroup 驱动程序，否则 kubelet 会报错并退出。这让许多集群管理员头疼不已。不过，现在曙光乍现！

Kubernetes 1.31：流式传输从 SPDY 转换为 WebSocket

Tue, 20 Aug 2024 00:00:00 +0000

在 Kubernetes 1.31 中，kubectl 现在默认使用 WebSocket 协议而不是 SPDY 进行流式传输。

这篇文章介绍了这些变化对你意味着什么以及这些流式传输 API 的重要性。

Kubernetes 中的流式 API

在 Kubernetes 中，某些以 HTTP 或 RESTful 接口公开的某些端点会被升级为流式连接，因而需要使用流式协议。与 HTTP 这种请求-响应协议不同，流式协议提供了一种持久的双向连接，具有低延迟的特点，并允许实时交互。流式协议支持在客户端与服务器之间通过同一个连接进行双向的数据读写。这种类型的连接非常有用，例如，当你从本地工作站在某个运行中的容器内创建 shell 并在该容器中运行命令时。

Kubernetes 1.31：针对 Job 的 Pod 失效策略进阶至 GA

Mon, 19 Aug 2024 00:00:00 +0000

这篇博文阐述在 Kubernetes 1.31 中进阶至 Stable 的 Pod 失效策略，还介绍如何在你的 Job 中使用此策略。

关于 Pod 失效策略

当你在 Kubernetes 上运行工作负载时，Pod 可能因各种原因而失效。理想情况下，像 Job 这样的工作负载应该能够忽略瞬时的、可重试的失效，并继续运行直到完成。

Kubernetes 1.31：podAffinity 中的 matchLabelKeys 进阶至 Beta

Fri, 16 Aug 2024 00:00:00 +0000

Kubernetes 1.29 在 podAffinity 和 podAntiAffinity 中引入了新的字段 matchLabelKeys 和 mismatchLabelKeys。

在 Kubernetes 1.31 中，此特性进阶至 Beta，并且相应的特性门控（MatchLabelKeysInPodAffinity）默认启用。

`matchLabelKeys` - 为多样化滚动更新增强了调度

在工作负载（例如 Deployment）的滚动更新期间，集群中可能同时存在多个版本的 Pod。
然而，调度器无法基于 podAffinity 或 podAntiAffinity 中指定的 labelSelector 区分新旧版本。结果，调度器将并置或分散调度 Pod，不会考虑这些 Pod 的版本。

Kubernetes 1.31：防止无序删除时 PersistentVolume 泄漏

Fri, 16 Aug 2024 00:00:00 +0000

PersistentVolume（简称 PV）具有与之关联的回收策略。回收策略用于确定在删除绑定到 PV 的 PVC 时存储后端需要采取的操作。当回收策略为 Delete 时，期望存储后端释放为 PV 所分配的存储资源。实际上，在 PV 被删除时就需要执行此回收策略。

Kubernetes 1.31：基于 OCI 工件的只读卷 (Alpha)

Fri, 16 Aug 2024 00:00:00 +0000

Kubernetes 社区正朝着在未来满足更多人工智能（AI）和机器学习（ML）使用场景的方向发展。虽然此项目在过去设计为满足微服务架构，但现在是时候听听最终用户的声音并引入更侧重于 AI/ML 的特性了。

Kubernetes 1.31：通过 VolumeAttributesClass 修改卷进阶至 Beta

Thu, 15 Aug 2024 00:00:00 +0000

在 Kubernetes 中，卷由两个属性描述：存储类和容量。存储类是卷的不可变属性，而容量可以通过卷调整大小进行动态变更。

Kubernetes v1.31：通过基于缓存的一致性读加速集群性能

Thu, 15 Aug 2024 00:00:00 +0000

Kubernetes 以其强大的容器化应用编排能力而闻名，但随着集群规模扩大，对控制平面的需求可能成为性能瓶颈。其中一个主要挑战是确保从 etcd 数据存储进行强一致性读，这通常需要资源密集型仲裁读取操作。

Kubernetes 1.31：对 cgroup v1 的支持转为维护模式

Wed, 14 Aug 2024 00:00:00 +0000

随着 Kubernetes 不断发展，为了适应容器编排全景图的变化，社区决定在 v1.31 中将对 cgroup v1 的支持转为维护模式。这一转变与行业更广泛地向 cgroup v2 的迁移保持一致，后者的功能更强，包括可扩展性和更加一致的接口。在我们深入探讨对 Kubernetes 的影响之前，先回顾一下 cgroup 的概念及其在 Linux 中的重要意义。

Kubernetes v1.31: PersistentVolume 的最后阶段转换时间进阶到 GA

Wed, 14 Aug 2024 00:00:00 +0000

现在宣布 PersistentVolume 的 lastTransitionTime 状态字段在 Kubernetes v1.31 版本进阶至正式发布（GA）！

Kubernetes v1.31: Elli

Tue, 13 Aug 2024 00:00:00 +0000

编辑: Matteo Bianchi, Yigit Demirbas, Abigail McCarthy, Edith Puclla, Rashan Smith

向 Client-Go 引入特性门控：增强灵活性和控制力

Mon, 12 Aug 2024 00:00:00 +0000

Kubernetes 组件使用称为“特性门控（Feature Gates）”的开关来管理添加新特性的风险，特性门控机制使特性能够通过 Alpha、Beta 和 GA 阶段逐步升级。

聚焦 SIG API Machinery

Wed, 07 Aug 2024 00:00:00 +0000

我们最近与 SIG API Machinery 的主席 Federico Bongiovanni（Google）和 David Eads（Red Hat）进行了访谈，了解一些有关这个 Kubernetes 特别兴趣小组的信息。

介绍

Frederico (FSM)：你好，感谢你抽时间参与访谈。首先，你能做个自我介绍以及你是如何参与到 Kubernetes 的？

Kubernetes v1.31 中的移除和主要变更

Fri, 19 Jul 2024 00:00:00 +0000

随着 Kubernetes 的发展和成熟，为了项目的整体健康，某些特性可能会被弃用、删除或替换为更好的特性。本文阐述了 Kubernetes v1.31 版本的一些更改计划，发行团队认为你应当了解这些更改，以便持续维护 Kubernetes 环境。下面列出的信息基于 v1.31 版本的当前状态；这些状态可能会在实际发布日期之前发生变化。

Kubernetes 的十年

Thu, 06 Jun 2024 00:00:00 +0000

完成 Kubernetes 史上最大规模迁移

Mon, 20 May 2024 00:00:00 +0000

早自 Kubernetes v1.7 起，Kubernetes 项目就开始追求取消集成内置云驱动（KEP-2395）。虽然这些集成对于 Kubernetes 的早期发展和增长发挥了重要作用，但它们的移除是由两个关键因素驱动的：为各云启动维护数百万行 Go 代码的原生支持所带来的日趋增长的复杂度，以及将 Kubernetes 打造为真正的供应商中立平台的愿景。

Gateway API v1.1：服务网格、GRPCRoute 和更多变化

Thu, 09 May 2024 09:00:00 -0800

Kubernetes 1.30：防止未经授权的卷模式转换进阶到 GA

Tue, 30 Apr 2024 00:00:00 +0000

作者: Raunak Pradip Shah (Mirantis)

译者: Xin Li (DaoCloud)

随着 Kubernetes 1.30 的发布，防止修改从 Kubernetes 集群中现有 VolumeSnapshot 创建的 PersistentVolumeClaim 的卷模式的特性已被升级至 GA！

Kubernetes 1.30：结构化身份认证配置进阶至 Beta

Thu, 25 Apr 2024 00:00:00 +0000

在 Kubernetes 1.30 中，我们（SIG Auth）将结构化身份认证配置（Structured Authentication Configuration）进阶至 Beta。

Kubernetes 1.30：验证准入策略 ValidatingAdmissionPolicy 正式发布

Wed, 24 Apr 2024 00:00:00 +0000

我代表 Kubernetes 项目组成员，很高兴地宣布 ValidatingAdmissionPolicy 已经作为 Kubernetes 1.30 发布的一部分正式发布。如果你还不了解这个全新的声明式验证准入 Webhook 的替代方案，请参阅有关这个新特性的上一篇博文。如果你已经对 ValidatingAdmissionPolicy 有所了解并且想要尝试一下，那么现在是最好的时机。

Kubernetes 1.30：只读卷挂载终于可以真正实现只读了

Tue, 23 Apr 2024 00:00:00 +0000

作者: Akihiro Suda (NTT)

译者: Xin Li (DaoCloud)

只读卷挂载从一开始就是 Kubernetes 的一个特性。令人惊讶的是，在 Linux 上的某些条件下，只读挂载并不是完全只读的。从 v1.30 版本开始，这类卷挂载可以被处理为完全只读；v1.30 为递归只读挂载提供 Alpha 支持。

Kubernetes 1.30：对 Pod 使用用户命名空间的支持进阶至 Beta

Mon, 22 Apr 2024 00:00:00 +0000

Linux 提供了不同的命名空间来将进程彼此隔离。例如，一个典型的 Kubernetes Pod 运行在一个网络命名空间中可以隔离网络身份，运行在一个 PID 命名空间中可以隔离进程。

SIG Architecture 特别报道：代码组织

Thu, 11 Apr 2024 00:00:00 +0000

作者: Frederico Muñoz (SAS Institute)

译者: Xin Li (DaoCloud)

这是 SIG Architecture Spotlight 系列的第三次采访，该系列将涵盖不同的子项目。我们将介绍 SIG Architecture：代码组织。

Windows 操作就绪规范简介

Wed, 03 Apr 2024 00:00:00 +0000

自从 2019 年 Kubernetes 1.14 将对 Windows 的支持升级为稳定版以来，能够运行 Windows 工作负载的能力一直深受最终用户社区的认可。对于大型企业来说，对 Windows 工作负载支持的水平和可用性一直是各大企业选择 Kubernetes 发行版的重要差异化因素。然而，随着越来越多的 Windows 工作负载迁移到 Kubernetes，以及新的 Windows 特性不断发布，要高效且标准化地测试 Windows 工作节点变得越来越具有挑战性。

Kubernetes v1.30 初探

Tue, 12 Mar 2024 00:00:00 +0000

作者: Amit Dsouza, Frederick Kautz, Kristin Martin, Abigail McCarthy, Natali Vlatko

译者: Paco Xu (DaoCloud)

快速预览：Kubernetes v1.30 中令人兴奋的变化

新年新版本，v1.30 发布周期已过半，我们将迎来一系列有趣且令人兴奋的增强功能。从全新的 alpha 特性，到已有的特性升级为稳定版，再到期待已久的改进，这个版本对每个人都有值得关注的内容！

走进 Kubernetes 读书会（Book Club）

Thu, 22 Feb 2024 00:00:00 +0000

学习 Kubernetes 及其整个生态的技术并非易事。在本次采访中，我们的访谈对象是 Carlos Santana (AWS)，了解他是如何创办 Kubernetes 读书会（Book Club）的，整个读书会是如何运作的，以及大家如何加入其中，进而更好地利用社区学习体验。

镜像文件系统：配置 Kubernetes 将容器存储在独立的文件系统上

Tue, 23 Jan 2024 00:00:00 +0000

作者: Kevin Hannon (Red Hat)

译者: Michael Yao

磁盘空间不足是运行或操作 Kubernetes 集群时的一个常见问题。在制备节点时，你应该为容器镜像和正在运行的容器留足够的存储空间。容器运行时通常会向 /var 目录写入数据。此目录可以位于单独的分区或根文件系统上。CRI-O 默认将其容器和镜像写入 /var/lib/containers，而 containerd 将其容器和镜像写入 /var/lib/containerd。

Kubernetes 1.29 中的上下文日志生成：更好的故障排除和增强的日志记录

Wed, 20 Dec 2023 09:30:00 -0800

作者：Mengjiao Liu (DaoCloud), Patrick Ohly (Intel)

译者：Mengjiao Liu (DaoCloud)

代表结构化日志工作组和 SIG Instrumentation，我们很高兴地宣布在 Kubernetes v1.24 中引入的上下文日志记录功能现已成功迁移了两个组件（kube-scheduler 和 kube-controller-manager）以及一些目录。该功能旨在为 Kubernetes 提供更多有用的日志以更好地进行故障排除，并帮助开发人员增强 Kubernetes。

Kubernetes 1.29: 解耦污点管理器与节点生命周期控制器

Tue, 19 Dec 2023 00:00:00 +0000

作者: Yuan Chen (Apple), Andrea Tosatto (Apple)

译者: Allen Zhang

这篇博客讨论在 Kubernetes 1.29 中基于污点的 Pod 驱逐处理的新特性。

背景

在 Kubernetes 1.29 中引入了一项改进，以加强节点上基于污点的 Pod 驱逐处理。本文将讨论对节点生命周期控制器（node-lifecycle-controller）所做的更改，以分离职责并提高代码的整体可维护性。

Kubernetes 1.29：PodReadyToStartContainers 状况进阶至 Beta

Tue, 19 Dec 2023 00:00:00 +0000

作者：Zefeng Chen (independent), Kevin Hannon (Red Hat)

译者：Michael Yao

随着最近发布的 Kubernetes 1.29，PodReadyToStartContainers 状况默认可用。 kubelet 在 Pod 的整个生命周期中管理该状况的值，将其存储在 Pod 的状态字段中。 kubelet 将通过容器运行时从 Pod 沙箱创建和网络配置的角度使用 PodReadyToStartContainers 状况准确地展示 Pod 的初始化状态，

Kubernetes 1.29 新的 Alpha 特性：Service 的负载均衡器 IP 模式

Mon, 18 Dec 2023 00:00:00 +0000

作者： Aohan Yang

译者： Allen Zhang

本文介绍 Kubernetes 1.29 中一个新的 Alpha 特性。此特性提供了一种可配置的方式用于定义 Service 的实现方式，本文中以 kube-proxy 为例介绍如何处理集群内从 Pod 到 Service 的流量。

Kubernetes 1.29：修改卷之 VolumeAttributesClass

Fri, 15 Dec 2023 00:00:00 +0000

译者：Baofa Fan (DaoCloud)

Kubernetes v1.29 版本引入了一个 Alpha 功能，支持通过变更 PersistentVolumeClaim（PVC）的 volumeAttributesClassName 字段来修改卷。启用该功能后，Kubernetes 可以处理除容量以外的卷属性的更新。允许更改卷属性，而无需通过不同提供商的 API 对其进行管理，这直接简化了当前流程。

聚焦 SIG Testing

Fri, 24 Nov 2023 00:00:00 +0000

作者: Sandipan Panda

译者: Michael Yao

欢迎阅读又一期的 “SIG 聚光灯” 系列博客，这些博客重点介绍 Kubernetes 项目中各个特别兴趣小组（SIG）所从事的令人赞叹的工作。这篇博客将聚焦 SIG Testing，这是一个致力于有效测试 Kubernetes，让此项目的繁琐工作实现自动化的兴趣小组。 SIG Testing 专注于创建和运行工具和基础设施，使社区更容易编写和运行测试，并对测试结果做贡献、分析和处理。

Kubernetes 1.29 中的移除、弃用和主要变更

Thu, 16 Nov 2023 00:00:00 +0000

作者: Carol Valencia, Kristin Martin, Abigail McCarthy, James Quigley, Hosam Kamel

译者: Michael Yao (DaoCloud)

和其他每次发布一样，Kubernetes v1.29 将弃用和移除一些特性。一贯以来生成高质量发布版本的能力是开发周期稳健和社区健康的证明。下文列举即将发布的 Kubernetes 1.29 中的一些弃用和移除事项。

介绍 SIG etcd

Tue, 07 Nov 2023 00:00:00 +0000

作者：Han Kang (Google), Marek Siarkowicz (Google), Frederico Muñoz (SAS Institute)

译者：Xin Li (Daocloud)

特殊兴趣小组（SIG）是 Kubernetes 项目的基本组成部分，很大一部分的 Kubernetes 社区活动都在其中进行。当有需要时，可以创建新的 SIG，而这正是最近发生的事情。

Gateway API v1.0：正式发布（GA）

Tue, 31 Oct 2023 10:00:00 -0800

作者： Shane Utt (Kong), Nick Young (Isovalent), Rob Scott (Google)

译者： Xin Li (Daocloud)

我们代表 Kubernetes SIG Network 很高兴地宣布 Gateway API v1.0 版本发布！此版本是该项目的一个重要里程碑。几个关键的 API 正在逐步进入 GA（正式发布）阶段，同时其他重要特性已添加到实验（Experimental）通道中。

Kubernetes 中 PersistentVolume 的最后阶段转换时间

Mon, 23 Oct 2023 00:00:00 +0000

作者： Roman Bednář (Red Hat)

译者： Xin Li (DaoCloud)

在最近的 Kubernetes v1.28 版本中，我们（SIG Storage）引入了一项新的 Alpha 级别特性，旨在改进 PersistentVolume（PV）存储管理并帮助集群管理员更好地了解 PV 的生命周期。通过将 lastPhaseTransitionTime 字段添加到 PV 的状态中，集群管理员现在可以跟踪 PV 上次转换到不同阶段的时间，从而实现更高效、更明智的资源管理。

2023 中国 Kubernetes 贡献者峰会简要回顾

Fri, 20 Oct 2023 00:00:00 +0000

作者： Paco Xu 和 Michael Yao (DaoCloud)

2023 年 9 月 26 日，即 KubeCon + CloudNativeCon + Open Source Summit China 2023 第一天，近 50 位社区贡献者济济一堂，在上海聚首 Kubernetes 贡献者峰会。

CRI-O 正迁移至 pkgs.k8s.io

Tue, 10 Oct 2023 00:00:00 +0000

作者：Sascha Grunert

译者：Wilson Wu (DaoCloud)

Kubernetes 社区最近宣布旧的软件包仓库已被冻结，现在这些软件包将被迁移到由 OpenBuildService（OBS）提供支持的社区自治软件包仓库中。很久以来，CRI-O 一直在利用 OBS 进行软件包构建，但到目前为止，所有打包工作都是手动完成的。

聚焦 SIG Architecture: Conformance

Thu, 05 Oct 2023 00:00:00 +0000

作者：Frederico Muñoz (SAS Institute)

译者：Michael Yao (DaoCloud)

这是 SIG Architecture 焦点访谈系列的首次采访，这一系列访谈将涵盖多个子项目。我们从 SIG Architecture：Conformance 子项目开始。

公布 2023 年指导委员会选举结果

Mon, 02 Oct 2023 00:00:00 +0000

作者：Kaslin Fields

译者：Xin Li(DaoCloud)

2023 年指导委员会选举现已完成。 Kubernetes 指导委员会由 7 个席位组成，其中 4 个席位于 2023 年进行选举。新任委员会成员的任期为 2 年，所有成员均由 Kubernetes 社区选举产生。

kubeadm 七周年生日快乐！

Tue, 26 Sep 2023 00:00:00 +0000

作者: Fabrizio Pandini (VMware)

译者: Michael Yao (DaoCloud)

回首向来萧瑟处，七年光阴风雨路！

kubeadm：使用 etcd Learner 安全地接入控制平面节点

Mon, 25 Sep 2023 00:00:00 +0000

作者: Paco Xu (DaoCloud)

译者: Michael Yao (DaoCloud)

kubeadm 工具现在支持 etcd learner 模式，借助 etcd 3.4 版本引入的 learner 模式特性，可以提高 Kubernetes 集群的弹性和稳定性。本文将介绍如何在 kubeadm 中使用 etcd learner 模式。默认情况下，kubeadm 在每个控制平面节点上运行一个本地 etcd 实例。

用户命名空间：对运行有状态 Pod 的支持进入 Alpha 阶段!

Wed, 13 Sep 2023 00:00:00 +0000

作者： Rodrigo Campos Catelin (Microsoft), Giuseppe Scrivano (Red Hat), Sascha Grunert (Red Hat)

译者： Xin Li (DaoCloud)

Kubernetes v1.25 引入用户命名空间（User Namespace）特性，仅支持无状态（Stateless）Pod。 Kubernetes 1.28 在 1.27 的基础上中进行了一些改进后，取消了这一限制。

比较本地 Kubernetes 开发工具：Telepresence、Gefyra 和 mirrord

Tue, 12 Sep 2023 00:00:00 +0000

作者: Eyal Bukchin (MetalBear)

译者: Michael Yao (DaoCloud)

Kubernetes 的开发周期是一个不断演化的领域，有许多工具在寻求简化这个过程。每个工具都有其独特的方法，具体选择通常取决于各个项目的要求、团队的专业知识以及所偏好的工作流。

Kubernetes 旧版软件包仓库将于 2023 年 9 月 13 日被冻结

Thu, 31 Aug 2023 15:30:00 -0700

2023 年 8 月 15 日，Kubernetes 项目宣布社区拥有的 Debian 和 RPM 软件包仓库在 pkgs.k8s.io 上正式提供。新的软件包仓库将取代旧的由 Google 托管的软件包仓库：apt.kubernetes.io 和 yum.kubernetes.io。 pkgs.k8s.io 的公告博客文章强调我们未来将停止将软件包发布到旧仓库。

Gateway API v0.8.0：引入服务网格支持

Tue, 29 Aug 2023 10:00:00 -0800

作者： Flynn (Buoyant), John Howard (Google), Keith Mattix (Microsoft), Michael Beaumont (Kong), Mike Morris (independent), Rob Scott (Google)

译者： Xin Li (Daocloud)

我们很高兴地宣布 Gateway API 的 v0.8.0 版本发布了！通过此版本，Gateway API 对服务网格的支持已达到实验性（Experimental）状态。我们期待你的反馈！

Kubernetes 1.28：用于改进集群安全升级的新（Alpha）机制

Mon, 28 Aug 2023 00:00:00 +0000

作者： Richa Banker (Google)

译者： Xin Li (DaoCloud)

本博客介绍了混合版本代理（Mixed Version Proxy），这是 Kubernetes 1.28 中的一个新的 Alpha 级别特性。当集群中存在多个不同版本的 API 服务器时，混合版本代理使对资源的 HTTP 请求能够被正确的 API 服务器处理。例如，在集群升级期间或当发布集群控制平面的运行时配置时此特性非常有用。

Kubernetes v1.28：介绍原生边车容器

Fri, 25 Aug 2023 00:00:00 +0000

作者：Todd Neal (AWS), Matthias Bertschy (ARMO), Sergey Kanzhelev (Google), Gunju Kim (NAVER), Shannon Kularathna (Google)

本文介绍了如何使用新的边车（Sidecar）功能，该功能支持可重新启动的 Init 容器，并且在 Kubernetes 1.28 以 Alpha 版本发布。我们希望得到你的反馈，以便我们尽快完成此功能。

Kubernetes 1.28：在 Linux 上使用交换内存的 Beta 支持

Thu, 24 Aug 2023 10:00:00 -0800

作者：Itamar Holder (Red Hat)

译者：Wilson Wu (DaoCloud)

Kubernetes 1.22 版本为交换内存引入了一项 Alpha 支持，用于为在 Linux 节点上运行的 Kubernetes 工作负载逐个节点地配置交换内存使用。现在，在 1.28 版中，对 Linux 节点上的交换内存的支持已升级为 Beta 版，并有许多新的改进。

Kubernetes 1.28：节点 podresources API 正式发布

Wed, 23 Aug 2023 00:00:00 +0000

作者：Francesco Romani (Red Hat)

译者：Wilson Wu (DaoCloud)

podresources API 是由 kubelet 提供的节点本地 API，它用于公开专门分配给容器的计算资源。随着 Kubernetes 1.28 的发布，该 API 现已正式发布。

Kubernetes 1.28：Job 失效处理的改进

Mon, 21 Aug 2023 00:00:00 +0000

作者： Kevin Hannon (G-Research), Michał Woźniak (Google)

译者： Xin Li (Daocloud)

本博客讨论 Kubernetes 1.28 中的两个新特性，用于为批处理用户改进 Job： Pod 更换策略和基于索引的回退限制。

这些特性延续了 Pod 失效策略为开端的工作，用来改进对 Job 中 Pod 失效的处理。

Kubernetes v1.28：可追溯的默认 StorageClass 进阶至 GA

Fri, 18 Aug 2023 00:00:00 +0000

作者: Roman Bednář (Red Hat)

译者: Michael Yao (DaoCloud)

可追溯的默认 StorageClass 赋值（Retroactive Default StorageClass Assignment）在 Kubernetes v1.28 中宣布进阶至正式发布（GA）！

Kubernetes SIG Storage 团队非常高兴地宣布，在 Kubernetes v1.25 中作为 Alpha 特性引入的 “可追溯默认 StorageClass 赋值” 现已进阶至 GA，并正式成为 Kubernetes v1.28 发行版的一部分。这项增强特性极大地改进了默认的 StorageClasses 为 PersistentVolumeClaim (PVC) 赋值的方式。

Kubernetes 1.28: 节点非体面关闭进入 GA 阶段（正式发布）

Wed, 16 Aug 2023 10:00:00 -0800

作者： Xing Yang (VMware) 和 Ashutosh Kumar (Elastic)

译者： Xin Li (Daocloud)

Kubernetes 节点非体面关闭特性现已在 Kubernetes v1.28 中正式发布。

pkgs.k8s.io：介绍 Kubernetes 社区自有的包仓库

Tue, 15 Aug 2023 20:00:00 +0000

我很高兴代表 Kubernetes SIG Release 介绍 Kubernetes 社区自有的 Debian 和 RPM 软件仓库：pkgs.k8s.io！这些全新的仓库取代了我们自 Kubernetes v1.5 以来一直使用的托管在 Google 的仓库（apt.kubernetes.io 和 yum.kubernetes.io）。

聚焦 SIG CLI

Thu, 20 Jul 2023 00:00:00 +0000

作者：Arpit Agrawal

译者：Xin Li (Daocloud)

在 Kubernetes 的世界中，大规模管理容器化应用程序需要强大而高效的工具。命令行界面（CLI）是任何开发人员或操作人员工具包不可或缺的一部分，其提供了一种方便灵活的方式与 Kubernetes 集群交互。

Kubernetes 机密：使用机密虚拟机和安全区来增强你的集群安全性

Thu, 06 Jul 2023 00:00:00 +0000

作者：Fabian Kammel (Edgeless Systems), Mikko Ylinen (Intel), Tobin Feldman-Fitzthum (IBM)

译者：顾欣

在这篇博客文章中，我们将介绍机密计算（Confidential Computing，简称 CC）的概念，以增强任何计算环境的安全和隐私属性。此外，我们将展示云原生生态系统，特别是 Kubernetes，如何从新的计算范式中受益。

在 CRI 运行时内验证容器镜像签名

Thu, 29 Jun 2023 00:00:00 +0000

作者: Sascha Grunert

译者: Michael Yao (DaoCloud)

Kubernetes 社区自 v1.24 版本开始对基于容器镜像的工件进行签名。在 v1.26 中，相应的增强特性从 alpha 进阶至 beta，引入了针对二进制工件的签名。其他项目也采用了类似的方法，为其发布版本提供镜像签名。这意味着这些项目要么使用 GitHub actions 在自己的 CI/CD 流程中创建签名，要么依赖于 Kubernetes 的镜像推广流程，通过向 k/k8s.io 仓库提交 PR 来自动签名镜像。使用此流程的前提要求是项目必须属于 kubernetes 或 kubernetes-sigs GitHub 组织，这样能够利用社区基础设施将镜像推送到暂存桶中。

dl.k8s.io 采用内容分发网络（CDN）

Fri, 09 Jun 2023 00:00:00 +0000

作者：Arnaud Meukam (VMware), Hannah Aubry (Fast Forward), Frederico Muñoz (SAS Institute)

译者：Xin Li (Daocloud)

我们很高兴地宣布，官方 Kubernetes 二进制文件的主页 dl.k8s.io 很快将由 Fastly 提供支持。

使用 OCI 工件为 seccomp、SELinux 和 AppArmor 分发安全配置文件

Wed, 24 May 2023 00:00:00 +0000

作者: Sascha Grunert

译者: Michael Yao (DaoCloud)

Security Profiles Operator (SPO) 使得在 Kubernetes 中管理 seccomp、SELinux 和 AppArmor 配置文件变得更加容易。它允许集群管理员在预定义的自定义资源 YAML 中定义配置文件，然后由 SPO 分发到整个集群中。安全配置文件的修改和移除也由 Operator 以同样的方式进行管理，但这只是其能力的一小部分。

在边缘上玩转 seccomp 配置文件

Thu, 18 May 2023 00:00:00 +0000

作者: Sascha Grunert

译者: Michael Yao (DaoCloud)

[Security Profiles Operator (SPO)][spo] 是一个功能丰富的 Kubernetes [operator][operator]，相比以往可以简化 seccomp、SELinux 和 AppArmor 配置文件的管理。从头开始记录这些配置文件是该 Operator 的关键特性之一，这通常涉及与大型 CI/CD 系统集成。在边缘场景中测试 Operator 的记录能力是 SPO 的最新开发工作之一，非常有助于轻松玩转 seccomp 配置文件。

Kubernetes 1.27: KMS V2 进入 Beta 阶段

Tue, 16 May 2023 00:00:00 +0000

作者： Anish Ramasekar, Mo Khan, and Rita Zhang (Microsoft)

译者： Xin Li (DaoCloud)

在 Kubernetes 1.27 中，我们（SIG Auth）将密钥管理服务（KMS）v2 API 带入 Beta 阶段。

KMS 是什么？

保护 Kubernetes 集群时首先要考虑的事情之一是加密静态的 etcd 数据。 KMS 为供应商提供了一个接口，以便利用存储在外部密钥服务中的密钥来执行此加密。

Kubernetes 1.27：关于加快 Pod 启动的进展

Mon, 15 May 2023 00:00:00 +0000

作者：Paco Xu (DaoCloud), Sergey Kanzhelev (Google), Ruiwen Zhao (Google) 译者：Michael Yao (DaoCloud)

如何在大型集群中加快节点上的 Pod 启动？这是集群管理员可能面临的常见问题。

Kubernetes 1.27: 原地调整 Pod 资源 (alpha)

Fri, 12 May 2023 00:00:00 +0000

作者: Vinay Kulkarni (Kubescaler Labs)

译者：Paco Xu (Daocloud)

如果你部署的 Pod 设置了 CPU 或内存资源，你就可能已经注意到更改资源值会导致 Pod 重新启动。以前，这对于运行的负载来说是一个破坏性的操作。

Kubernetes 1.27：为 NodePort Service 分配端口时避免冲突

Thu, 11 May 2023 00:00:00 +0000

作者: Xu Zhenglun (Alibaba)

译者: Michael Yao (DaoCloud)

在 Kubernetes 中，对于以一组 Pod 运行的应用，Service 可以为其提供统一的流量端点。客户端可以使用 Service 提供的虚拟 IP 地址（或 VIP）进行访问， Kubernetes 为访问不同的后端 Pod 的流量提供负载均衡能力，但 ClusterIP 类型的 Service 仅限于供集群内的节点来访问，而来自集群外的流量无法被路由。解决这个难题的一种方式是使用 type: NodePort Service，这种服务会在集群所有节点上为特定端口建立映射关系，从而将来自集群外的流量重定向到集群内。

Kubernetes 1.27：kubectl apply 裁剪更安全、更高效

Tue, 09 May 2023 00:00:00 +0000

作者: Katrina Verey（独立个人）和 Justin Santa Barbara (Google)

译者: Michael Yao (DaoCloud)

通过 kubectl apply 命令执行声明式配置管理是创建或修改 Kubernetes 资源的黄金标准方法。但这种方法也带来了一个挑战，那就是删除不再需要的资源。在 Kubernetes 1.5 版本中，引入了 --prune 标志来解决此问题，允许 kubectl apply 自动清理从当前配置中删除的先前应用的资源。

Kubernetes 1.27：介绍用于磁盘卷组快照的新 API

Mon, 08 May 2023 00:00:00 +0000

Author: Xing Yang (VMware)

译者: 顾欣

磁盘卷组快照在 Kubernetes v1.27 中作为 Alpha 特性被引入。此特性引入了一个 Kubernetes API，允许用户对多个卷进行快照，以保证在发生故障时数据的一致性。它使用标签选择器来将多个 PersistentVolumeClaims （持久卷申领）分组以进行快照。这个新特性仅支持 CSI 卷驱动器。

Kubernetes 1.27：内存资源的服务质量（QoS）Alpha

Fri, 05 May 2023 00:00:00 +0000

作者：Dixita Narang (Google)

译者：Wilson Wu (DaoCloud)

Kubernetes v1.27 于 2023 年 4 月发布，引入了对内存 QoS（Alpha）的更改，用于提高 Linux 节点中的内存管理功能。

对内存 QoS 的支持最初是在 Kubernetes v1.22 中添加的，后来发现了关于计算 memory.high 公式的一些不足。这些不足在 Kubernetes v1.27 中得到解决。

Kubernetes 1.27: StatefulSet PVC 自动删除(beta)

Thu, 04 May 2023 00:00:00 +0000

作者：Matthew Cary (Google)

译者：顾欣 (ICBC)

Kubernetes v1.27 将一种新的策略机制升级到 Beta 阶段，这一策略用于控制 StatefulSets 的 PersistentVolumeClaims（PVCs）的生命周期。这种新的 PVC 保留策略允许用户指定当删除 StatefulSet 或者缩减 StatefulSet 中的副本时，是自动删除还是保留从 StatefulSet 规约模板生成的 PVC。

Kubernetes 1.27：HorizontalPodAutoscaler ContainerResource 类型指标进阶至 Beta

Tue, 02 May 2023 12:00:00 +0800

作者: Kensei Nakada (Mercari)

译者: Michael Yao (DaoCloud)

Kubernetes 1.20 在 HorizontalPodAutoscaler (HPA) 中引入了 ContainerResource 类型指标。

在 Kubernetes 1.27 中，此特性进阶至 Beta，相应的特性门控 (HPAContainerMetrics) 默认被启用。

Kubernetes 1.27: StatefulSet 启动序号简化了迁移

Fri, 28 Apr 2023 00:00:00 +0000

作者： Peter Schuurman (Google)

译者： Xin Li (DaoCloud)

Kubernetes v1.26 为 StatefulSet 引入了一个新的 Alpha 级别特性，可以控制 Pod 副本的序号。从 Kubernetes v1.27 开始，此特性进级到 Beta 阶段。序数可以从任意非负数开始，这篇博文将讨论如何使用此功能。

官方自动刷新 CVE 订阅源的更新

Tue, 25 Apr 2023 00:00:00 +0000

作者：Cailyn Edwards (Shopify), Mahé Tardy (Isovalent), Pushkar Joglekar

译者：Wilson Wu (DaoCloud)

自从在 1.25 版本中将官方自动刷新 CVE 订阅源作为 Alpha 功能启用以来，我们已经做了一些重大改进和更新。我们很高兴宣布该订阅源的 Beta 版现已发布。这篇博文将列举收到的反馈、所做的更改，还讨论了在未来 Kubernetes 版本中准备使其进阶成为一个稳定功能时你可以如何提供帮助。

Kubernetes 1.27：服务器端字段校验和 OpenAPI V3 进阶至 GA

Mon, 24 Apr 2023 00:00:00 +0000

作者：Jeffrey Ying (Google), Antoine Pelisse (Google)

译者：Michael Yao (DaoCloud)

在 Kubernetes v1.8 之前，YAML 文件中的拼写错误、缩进错误或其他小错误可能会产生灾难性后果（例如像在 replica: 1000 中忘记了结尾的字母 “s”，可能会导致宕机。因为该值会被忽略并且丢失，并强制将副本重置回 1）。当时解决这个问题的办法是：在 kubectl 中获取 OpenAPI v2 并在应用之前使用 OpenAPI v2 来校验字段是否正确且存在。不过当时没有自定义资源定义 (CRD)，相关代码是在当时那样的假设下编写的。之后引入了 CRD，发现校验代码缺乏灵活性，迫使 CRD 在公开其模式定义时做出了一些艰难的决策，使得我们进入了不良校验造成不良 OpenAPI，不良 OpenAPI 无法校验的循环。随着新的 OpenAPI v3 和服务器端字段校验在 1.27 中进阶至 GA，我们现在已经解决了这两个问题。

Kubernetes 1.27: 使用 Kubelet API 查询节点日志

Fri, 21 Apr 2023 00:00:00 +0000

作者： Aravindh Puthiyaparambil (Red Hat)

译者： Xin Li (DaoCloud)

Kubernetes 1.27 引入了一个名为节点日志查询的新功能，可以查看节点上运行的服务的日志。

它解决了什么问题？

集群管理员在调试节点上运行的表现不正常的服务时会遇到问题。他们通常必须通过 SSH 或 RDP 进入节点以查看服务日志以调试问题。 节点日志查询功能通过允许集群管理员使用 kubectl 查看日志的方式来帮助解决这种情况。这对于 Windows 节点特别有用，在 Windows 节点中，你会遇到节点进入就绪状态但由于 CNI 错误配置和其他不易通过查看 Pod 状态来辨别的问题而导致容器无法启动的情况。

Kubernetes 1.27：持久卷的单个 Pod 访问模式升级到 Beta

Thu, 20 Apr 2023 00:00:00 +0000

作者：Chris Henzie (Google)

译者：顾欣 (ICBC)

随着 Kubernetes v1.27 的发布，ReadWriteOncePod 功能已经升级为 Beta 版。在这篇博客文章中，我们将更详细地介绍这个功能，作用以及在 Beta 版本中的发展。

Kubernetes 1.27：高效的 SELinux 卷重新标记（Beta 版）

Tue, 18 Apr 2023 10:00:00 -0800

作者：Jan Šafránek (Red Hat)

译者：Wilson Wu (DaoCloud)

问题

在启用了 Security-Enhancled Linux（SELinux）系统上，传统做法是让容器运行时负责为 Pod 及所有卷应用 SELinux 标签。 Kubernetes 仅将 SELinux 标签从 Pod 的 securityContext 字段传递给容器运行时。

Kubernetes 1.27：更多精细粒度的 Pod 拓扑分布策略进阶至 Beta

Mon, 17 Apr 2023 00:00:00 +0000

作者: Alex Wang (Shopee), Kante Yin (DaoCloud), Kensei Nakada (Mercari)

译者: Michael Yao (DaoCloud)

在 Kubernetes v1.19 中， Pod 拓扑分布约束进阶至正式发布 (GA)。

“使用更新后的 Go 版本保持 Kubernetes 安全”

Thu, 06 Apr 2023 00:00:00 +0000

作者：Jordan Liggitt (Google)

译者：顾欣 (ICBC)

问题

从 2020 年发布的 v1.19 版本以来，Kubernetes 项目为每个次要版本提供 12-14 个月的补丁维护期。这使得用户可以按照年度升级周期来评估和选用 Kubernetes 版本，并持续一年获得安全修复。

Kubernetes 验证准入策略：一个真实示例

Thu, 30 Mar 2023 00:00:00 +0000

作者：Craig Box (ARMO), Ben Hirschberg (ARMO)

译者：Xiaoyang Zhang (Huawei)

准入控制是 Kubernetes 控制平面的重要组成部分，在向服务器提交请求时，可根据批准或更改 API 对象的能力来实现多项内部功能。对于管理员来说，定义有关哪些对象可以进入集群的业务逻辑或策略是很有用的。为了更好地支持该场景， Kubernetes 在 v1.7 中引入了外部准入控制。

Kubernetes 在 v1.27 中移除的特性和主要变更

Fri, 17 Mar 2023 14:00:00 +0000

作者：Harshita Sao

译者：Michael Yao (DaoCloud)

随着 Kubernetes 发展和成熟，为了此项目的整体健康，某些特性可能会被弃用、移除或替换为优化过的特性。基于目前在 v1.27 发布流程中获得的信息，本文将列举并描述一些计划在 Kubernetes v1.27 发布中的变更，发布工作目前仍在进行中，可能会引入更多变更。

k8s.gcr.io 重定向到 registry.k8s.io - 用户须知

Fri, 10 Mar 2023 17:00:00 +0000

作者：Bob Killen (Google)、Davanum Srinivas (AWS)、Chris Short (AWS)、Frederico Muñoz (SAS Institute)、Tim Bannister (The Scale Factory)、Ricky Sadowski (AWS)、Grace Nguyen (Expo)、Mahamed Ali (Rackspace Technology)、Mars Toktonaliev（独立个人）、Laura Santamaria (Dell)、Kat Cosgrove (Dell)

Kubernetes 的容器检查点分析

Fri, 10 Mar 2023 00:00:00 +0000

作者：Adrian Reber (Red Hat)

译者：Paco Xu (DaoCloud)

我之前在 Kubernetes 中的取证容器检查点一文中，介绍了检查点以及如何创建和使用它。该特性的名称是取证容器检查点，但我没有详细介绍如何对 Kubernetes 创建的检查点进行实际分析。在本文中，我想提供如何分析检查点的详细信息。

介绍 KWOK（Kubernetes WithOut Kubelet，没有 Kubelet 的 Kubernetes）

Wed, 01 Mar 2023 00:00:00 +0000

作者: Shiming Zhang (DaoCloud), Wei Huang (Apple), Yibo Zhuang (Apple)

译者: Michael Yao (DaoCloud)

你是否曾想过在几秒钟内搭建一个由数千个节点构成的集群，如何用少量资源模拟真实的节点，如何不耗费太多基础设施就能大规模地测试你的 Kubernetes 控制器？

免费的 Katacoda Kubernetes 教程即将关闭

Tue, 14 Feb 2023 00:00:00 +0000

作者：Natali Vlatko，Kubernetes SIG Docs 联合主席

译者：Michael Yao (DaoCloud)

Katacoda 是 O’Reilly 开设的热门学习平台，帮助人们学习 Java、Docker、Kubernetes、Python、Go、C++ 和其他更多内容，这个学习平台于 2022 年 6 月停止对公众开放。但是，从 Kubernetes 网站为相关项目用户和贡献者关联的 Kubernetes 专门教程在那次变更后仍然可用并处于活跃状态。遗憾的是，接下来情况将发生变化，Katacoda 上有关学习 Kubernetes 的教程将在 2023 年 3 月 31 日之后彻底关闭。

k8s.gcr.io 镜像仓库将从 2023 年 4 月 3 日起被冻结

Mon, 06 Feb 2023 00:00:00 +0000

作者：Mahamed Ali (Rackspace Technology)

译者：Michael Yao (Daocloud)

Kubernetes 项目运行一个名为 registry.k8s.io、由社区管理的镜像仓库来托管其容器镜像。 2023 年 4 月 3 日，旧仓库 k8s.gcr.io 将被冻结，Kubernetes 及其相关子项目的镜像将不再推送到这个旧仓库。

聚光灯下的 SIG Instrumentation

Fri, 03 Feb 2023 00:00:00 +0000

作者: Imran Noor Mohamed (Delivery Hero)

译者: Kevin Yang

可观测性需要在合适的时间提供合适的数据，以便合适的消费者（人员或软件）做出正确的决策。在 Kubernetes 的环境中，拥有跨所有 Kubernetes 组件的集群可观测性最佳实践是至关重要的。

考虑所有微服务的脆弱性并对其行为进行监控

Fri, 20 Jan 2023 00:00:00 +0000

作者：David Hadas (IBM Research Labs)

译者：Wilson Wu (DaoCloud)

本文对 DevOps 产生的错误安全意识做出提醒。开发和配置微服务时遵循安全最佳实践并不能让微服务不易被攻击。本文说明，即使所有已部署的微服务都容易被攻击，但仍然可以采取很多措施来确保微服务不被利用。本文解释了如何从安全角度对客户端和服务的行为进行分析，此处称为 “安全行为分析” ，可以对已部署的易被攻击的微服务进行保护。本文会引用 Guard，一个开源项目，对假定易被攻击的 Kubernetes 微服务的安全行为提供监测与控制。

使用 PriorityClass 确保你的关键任务 Pod 免遭驱逐

Thu, 12 Jan 2023 00:00:00 +0000

作者：Sunny Bhambhani (InfraCloud Technologies)

译者：Wilson Wu (DaoCloud)

Kubernetes 已被广泛使用，许多组织将其用作事实上的编排引擎，用于运行需要频繁被创建和删除的工作负载。

Kubernetes 1.26：PodDisruptionBudget 守护的不健康 Pod 所用的驱逐策略

Fri, 06 Jan 2023 00:00:00 +0000

作者： Filip Křepinský (Red Hat), Morten Torkildsen (Google), Ravi Gudimetla (Apple)

译者： Michael Yao (DaoCloud)

确保对应用的干扰不影响其可用性不是一个简单的任务。上个月发布的 Kubernetes v1.26 允许针对 PodDisruptionBudget (PDB) 指定不健康 Pod 驱逐策略，这有助于在节点执行管理操作期间保持可用性。

Kubernetes v1.26：可追溯的默认 StorageClass

Thu, 05 Jan 2023 00:00:00 +0000

作者： Roman Bednář (Red Hat)

译者： Michael Yao (DaoCloud)

Kubernetes v1.25 引入了一个 Alpha 特性来更改默认 StorageClass 被分配到 PersistentVolumeClaim (PVC) 的方式。启用此特性后，你不再需要先创建默认 StorageClass，再创建 PVC 来分配类。此外，任何未分配 StorageClass 的 PVC 都可以在后续被更新。此特性在 Kubernetes v1.26 中已进阶至 Beta。

Kubernetes v1.26：对跨名字空间存储数据源的 Alpha 支持

Mon, 02 Jan 2023 00:00:00 +0000

作者： Takafumi Takahashi (Hitachi Vantara)

译者： Michael Yao (DaoCloud)

上个月发布的 Kubernetes v1.26 引入了一个 Alpha 特性，允许你在源数据属于不同的名字空间时为 PersistentVolumeClaim 指定数据源。启用这个新特性后，你在新 PersistentVolumeClaim 的 dataSourceRef 字段中指定名字空间。一旦 Kubernetes 发现访问权限正常，新的 PersistentVolume 就可以从其他名字空间中指定的存储源填充其数据。在 Kubernetes v1.26 之前，如果集群已启用了 AnyVolumeDataSource 特性，你可能已经从相同的名字空间中的数据源制备新卷。但这仅适用于同一名字空间中的数据源，因此用户无法基于一个名字空间中的数据源使用另一个名字空间中的声明来制备 PersistentVolume。为了解决这个问题，Kubernetes v1.26 在 PersistentVolumeClaim API 的 dataSourceRef 字段中添加了一个新的 Alpha namespace 字段。

Kubernetes v1.26：Kubernetes 中流量工程的进步

Fri, 30 Dec 2022 00:00:00 +0000

作者：Andrew Sy Kim (Google)

译者：Wilson Wu (DaoCloud)

Kubernetes v1.26 在网络流量工程方面取得了重大进展，两项功能（服务内部流量策略支持和 EndpointSlice 终止状况）升级为正式发布版本，第三项功能（代理终止端点）升级为 Beta。这些增强功能的结合旨在解决人们目前所面临的流量工程短板，并在未来解锁新的功能。

Kubernetes v1.26：CPUManager 正式发布

Tue, 27 Dec 2022 00:00:00 +0000

作者： Francesco Romani (Red Hat)

译者： Michael Yao (DaoCloud)

CPU 管理器是 kubelet 的一部分；kubelet 是 Kubernetes 的节点代理，能够让用户给容器分配独占 CPU。 CPU 管理器自从 Kubernetes v1.10 进阶至 Beta，已证明了它本身的可靠性，能够充分胜任将独占 CPU 分配给容器，因此采用率稳步增长，使其成为性能关键型和低延迟场景的基本组件。随着时间的推移，大多数变更均与错误修复或内部重构有关，以下列出了几个值得关注、用户可见的变更：

Kubernetes 1.26：Pod 调度就绪态

Mon, 26 Dec 2022 00:00:00 +0000

作者： Wei Huang (Apple), Abdullah Gharaibeh (Google)

译者： XiaoYang Zhang (HuaWei)

Kubernetes 1.26 引入了一个新的 Pod 特性：调度门控。在 Kubernetes 中，调度门控是通知调度器何时可以考虑 Pod 调度的关键。

Kubernetes 1.26: 支持在挂载时将 Pod fsGroup 传递给 CSI 驱动程序

Fri, 23 Dec 2022 00:00:00 +0000

作者： Fabio Bertinatto (Red Hat), Hemant Kumar (Red Hat)

译者： Xin Li (DaoCloud)

将 fsGroup 委托给 CSI 驱动程序管理首先在 Kubernetes 1.22 中作为 Alpha 特性引入，并在 Kubernetes 1.25 中进阶至 Beta 状态。对于 Kubernetes 1.26，我们很高兴地宣布此特性已进阶至正式发布（GA）状态。

Kubernetes 1.26：设备管理器正式发布

Mon, 19 Dec 2022 00:00:00 +0000

作者： Swati Sehgal (Red Hat)

译者： Jin Li (UOS)

设备插件框架是在 Kubernetes v1.8 版本中引入的，它是一个与供应商无关的框架，旨在实现对外部设备的发现、公布和分配，而无需修改核心 Kubernetes。该功能在 v1.10 版本中升级为 Beta 版本。随着 Kubernetes v1.26 的最新发布，设备管理器现已正式发布（GA）。

Kubernetes 1.26: 节点非体面关闭进入 Beta 阶段

Fri, 16 Dec 2022 10:00:00 -0800

作者： Xing Yang (VMware), Ashutosh Kumar (VMware)

Kubernetes 1.26: 动态资源分配 Alpha API

Thu, 15 Dec 2022 00:00:00 +0000

作者: Patrick Ohly (Intel)、Kevin Klues (NVIDIA)

译者： 空桐

动态资源分配是一个用于请求资源的新 API。它是对为通用资源所提供的持久卷 API 的泛化。它可以：

Kubernetes 1.26: 我们现在正在对二进制发布工件进行签名!

Mon, 12 Dec 2022 00:00:00 +0000

作者： Sascha Grunert

译者： XiaoYang Zhang (HUAWEI)

Kubernetes 特别兴趣小组 SIG Release 自豪地宣布，我们正在对所有发布工件进行数字签名，并且 Kubernetes 在这一方面现已达到 Beta。

签名工件为终端用户提供了验证下载资源完整性的机会。它可以直接在客户端减轻中间人攻击，从而确保远程服务工件的可信度。过去工作的总体目标是定义用于对所有 Kubernetes 相关工件进行签名的工具，以及为相关项目（例如 kubernetes-sigs 中的项目）提供标准签名流程。

Kubernetes 的取证容器检查点

Mon, 05 Dec 2022 00:00:00 +0000

作者: Adrian Reber (Red Hat)

取证容器检查点（Forensic container checkpointing）基于 CRIU（Checkpoint/Restore In Userspace ，用户空间的检查点/恢复），并允许创建正在运行的容器的有状态副本，而容器不知道它正在被检查。容器的副本，可以在沙箱环境中被多次分析和恢复，而原始容器并不知道。取证容器检查点是作为一个 alpha 特性在 Kubernetes v1.25 中引入的。

Kubernetes 1.26 中的移除、弃用和主要变更

Fri, 18 Nov 2022 00:00:00 +0000

作者：Frederico Muñoz (SAS)

变化是 Kubernetes 生命周期不可分割的一部分：随着 Kubernetes 成长和日趋成熟，为了此项目的健康发展，某些功能特性可能会被弃用、移除或替换为优化过的功能特性。 Kubernetes v1.26 也做了若干规划：根据 v1.26 发布流程中期获得的信息，本文将列举并描述其中一些变更，这些变更目前仍在进行中，可能会引入更多变更。

Kueue 介绍

Tue, 04 Oct 2022 00:00:00 +0000

作者： Abdullah Gharaibeh（谷歌），Aldo Culquicondor（谷歌）

无论是在本地还是在云端，集群都面临着资源使用、配额和成本管理方面的实际限制。无论自动扩缩容能力如何，集群的容量都是有限的。因此，用户需要一种简单的方法来公平有效地共享资源。

“Kubernetes 1.25：对使用用户名字空间运行 Pod 提供 Alpha 支持”

Mon, 03 Oct 2022 00:00:00 +0000

作者: Rodrigo Campos（Microsoft）、Giuseppe Scrivano（Red Hat）

Kubernetes v1.25 引入了对用户名字空间的支持。

这是在 Kubernetes 中运行安全工作负载的一项重大改进。每个 Pod 只能访问系统上可用 UID 和 GID 的有限子集，因此添加了一个新的安全层来保护 Pod 免受运行在同一系统上的其他 Pod 的影响。

Kubernetes 1.25：应用滚动上线所用的两个特性进入稳定阶段

Thu, 15 Sep 2022 00:00:00 +0000

作者： Ravi Gudimetla (Apple)、Filip Křepinský (Red Hat)、Maciej Szulik (Red Hat)

这篇博客描述了两个特性，即用于 StatefulSet 的 minReadySeconds 以及用于 DaemonSet 的 maxSurge， SIG Apps 很高兴宣布这两个特性在 Kubernetes 1.25 进入稳定阶段。

Kubernetes 1.25：Pod 新增 PodHasNetwork 状况

Wed, 14 Sep 2022 00:00:00 +0000

Kubernetes 1.25 引入了对 kubelet 所管理的新的 Pod 状况 PodHasNetwork 的 Alpha 支持，该状况位于 Pod 的 status 字段中。对于工作节点，kubelet 将使用 PodHasNetwork 状况从容器运行时（通常与 CNI 插件协作）创建 Pod 沙箱和网络配置的角度准确地了解 Pod 的初始化状态。在 PodHasNetwork 状况的 status 设置为 "True" 后，kubelet 开始拉取容器镜像并启动独立的容器（包括 Init 容器）。从集群基础设施的角度报告 Pod 初始化延迟的指标采集服务（无需知道每个容器的镜像大小或有效负载等特征）就可以利用 PodHasNetwork 状况来准确生成服务水平指标（Service Level Indicator，SLI）。某些管理底层 Pod 的 Operator 或控制器可以利用 PodHasNetwork 状况来优化 Pod 反复出现失败时要执行的操作。

宣布自动刷新官方 Kubernetes CVE 订阅源

Mon, 12 Sep 2022 00:00:00 +0000

作者：Pushkar Joglekar (VMware)

Kubernetes 的 iptables 链不是 API

Wed, 07 Sep 2022 00:00:00 +0000

作者： Dan Winship (Red Hat)

译者： Xin Li (DaoCloud)

一些 Kubernetes 组件（例如 kubelet 和 kube-proxy）在执行操作时，会创建特定的 iptables 链和规则。这些链从未被计划使其成为任何 Kubernetes API/ABI 保证的一部分，但一些外部组件仍然使用其中的一些链（特别是使用 KUBE-MARK-MASQ 将数据包标记为需要伪装）。

COSI 简介：使用 Kubernetes API 管理对象存储

Fri, 02 Sep 2022 00:00:00 +0000

作者： Sidhartha Mani (Minio, Inc)

本文介绍了容器对象存储接口 (COSI)，它是在 Kubernetes 中制备和使用对象存储的一个标准。它是 Kubernetes v1.25 中的一个 Alpha 功能。

Kubernetes 1.25: cgroup v2 升级到 GA

Wed, 31 Aug 2022 00:00:00 +0000

作者: David Porter (Google), Mrunal Patel (Red Hat)

Kubernetes 1.25 将 cgroup v2 正式发布（GA），让 kubelet 使用最新的容器资源管理能力。

什么是 cgroup？

有效的资源管理是 Kubernetes 的一个关键方面。这涉及管理节点中的有限资源，例如 CPU、内存和存储。

Kubernetes 1.25：CSI 内联存储卷正式发布

Mon, 29 Aug 2022 00:00:00 +0000

作者： Jonathan Dobson (Red Hat)

CSI 内联存储卷是在 Kubernetes 1.15 中作为 Alpha 功能推出的，并从 1.16 开始成为 Beta 版本。我们很高兴地宣布，这项功能在 Kubernetes 1.25 版本中正式发布（GA）。

PodSecurityPolicy：历史背景

Tue, 23 Aug 2022 15:00:00 -0800

作者： Mahé Tardy (Quarkslab)

从 Kubernetes v1.25 开始，PodSecurityPolicy (PSP) 准入控制器已被移除。在为 Kubernetes v1.21 发布的博文 PodSecurityPolicy 弃用：过去、现在和未来中，已经宣布并详细说明了它的弃用情况。

Kubernetes v1.25: Combiner

Tue, 23 Aug 2022 00:00:00 +0000

作者: Kubernetes 1.25 发布团队

宣布 Kubernetes v1.25 的发版！

这个版本总共包括 40 项增强功能。其中 15 项增强功能进入 Alpha，10 项进入 Beta，13 项进入 Stable。我们也废弃/移除了两个功能。

聚焦 SIG Storage

Mon, 22 Aug 2022 00:00:00 +0000

作者：Frederico Muñoz (SAS)

自 Kubernetes 诞生之初，持久数据以及如何解决有状态应用程序的需求一直是一个重要的话题。对无状态部署的支持是很自然的、从一开始就存在的，并引起了人们的关注，变得众所周知。从早期开始，我们也致力于更好地支持有状态应用程序，每个版本都增加了可以在 Kubernetes 上运行的范围。

认识我们的贡献者 - 亚太地区（中国地区）

Mon, 15 Aug 2022 00:00:00 +0000

作者和受访者： Avinesh Tripathi、 Debabrata Panigrahi、 Jayesh Srivastava、 Priyanka Saggu、 Purneswar Prasad、 Vedant Kakde

大家好 👋

逐个 KEP 地增强 Kubernetes

Thu, 11 Aug 2022 00:00:00 +0000

作者： Ryler Hockenbury（Mastercard）

你是否知道 Kubernetes v1.24 有 46 个增强特性？在为期 4 个月的发布周期内包含了大量新特性。 Kubernetes 发布团队协调发布的后勤工作，从修复测试问题到发布更新的文档。他们需要完成成吨的工作，但发布团队总是能按期交付。

Kubernetes 1.25 的移除说明和主要变更

Thu, 04 Aug 2022 00:00:00 +0000

作者：Kat Cosgrove、Frederico Muñoz、Debabrata Panigrahi

随着 Kubernetes 成长和日趋成熟，为了此项目的健康发展，某些功能特性可能会被弃用、移除或替换为优化过的功能特性。 Kubernetes v1.25 包括几个主要变更和一个主要移除。

Kubernetes API 移除和弃用流程

Kubernetes 项目对功能特性有一个文档完备的弃用策略。该策略规定，只有当较新的、稳定的相同 API 可用时，原有的稳定 API 才可能被弃用，每个稳定级别的 API 都有一个最短的生命周期。弃用的 API 指的是已标记为将在后续发行某个 Kubernetes 版本时移除的 API；移除之前该 API 将继续发挥作用（从弃用起至少一年时间），但使用时会显示一条警告。移除的 API 将在当前版本中不再可用，此时你必须迁移以使用替换的 API。

聚光灯下的 SIG Docs

Tue, 02 Aug 2022 00:00:00 +0000

作者： Purneswar Prasad

简介

官方文档是所有开源项目的首选资料源。对于 Kubernetes，它是一个持续演进的特别兴趣小组 (SIG)，人们持续不断努力制作详实的项目资料，让新贡献者和用户更容易取用这些文档。 SIG Docs 在 kubernetes.io 上发布官方文档，包括但不限于 Kubernetes 版本发布时附带的核心 API 文档、核心架构细节和 CLI 工具文档。

Kubernetes Gateway API 进入 Beta 阶段

Wed, 13 Jul 2022 00:00:00 +0000

作者： Shane Utt (Kong)、Rob Scott (Google)、Nick Young (VMware)、Jeff Apple (HashiCorp)

译者： Michael Yao (DaoCloud)

我们很高兴地宣布 Gateway API 的 v0.5.0 版本发布。我们最重要的几个 Gateway API 资源首次进入 Beta 阶段。此外，我们正在启动一项新的倡议，探索如何将 Gateway API 用于网格，还引入了 URL 重写等新的实验性概念。下文涵盖了这部分内容和更多说明。

2021 年度总结报告

Wed, 01 Jun 2022 00:00:00 +0000

作者： Paris Pittman（指导委员会）

去年，我们发布了第一期 2020 年度总结报告，现在已经是时候发布第二期了！

2021 年度总结报告

这份总结反映了 2021 年已完成的工作以及 2022 下半年置于台面上的倡议。请将这份总结转发给正参与上游活动、计划云原生战略和寻求帮助的那些组织和个人。若要查阅特定社区小组的完整报告，请访问 kubernetes/community 仓库查找各小组的文件夹。例如： sig-api-machinery/annual-report-2021.md

Kubernetes 1.24: StatefulSet 的最大不可用副本数

Fri, 27 May 2022 00:00:00 +0000

作者： Mayank Kumar (Salesforce)

译者： Xiaoyang Zhang（Huawei）

Kubernetes StatefulSet，自 1.5 版本中引入并在 1.9 版本中变得稳定以来，已被广泛用于运行有状态应用。它提供固定的 Pod 身份标识、每个 Pod 的持久存储以及 Pod 的有序部署、扩缩容和滚动更新功能。你可以将 StatefulSet 视为运行复杂有状态应用程序的原子构建块。随着 Kubernetes 的使用增多，需要 StatefulSet 的场景也越来越多。当 StatefulSet 的 Pod 管理策略为 OrderedReady 时，其中许多场景需要比当前所支持的一次一个 Pod 的更新更快的滚动更新。

Kubernetes 1.24 中的上下文日志记录

Wed, 25 May 2022 00:00:00 +0000

作者: Patrick Ohly (Intel)

结构化日志工作组在 Kubernetes 1.24 中为日志基础设施添加了新功能。这篇博文解释了开发者如何利用这些功能使日志输出更有用，以及他们如何参与改进 Kubernetes。

Kubernetes 1.24: 避免为 Services 分配 IP 地址时发生冲突

Mon, 23 May 2022 00:00:00 +0000

作者： Antonio Ojea (Red Hat)

在 Kubernetes 中，Services 是一种抽象，用来暴露运行在一组 Pod 上的应用。 Service 可以有一个集群范围的虚拟 IP 地址（使用 type: ClusterIP 的 Service）。客户端可以使用该虚拟 IP 地址进行连接， Kubernetes 为对该 Service 的访问流量提供负载均衡，以访问不同的后端 Pod。

Kubernetes 1.24: 节点非体面关闭特性进入 Alpha 阶段

Fri, 20 May 2022 00:00:00 +0000

作者：Xing Yang 和 Yassine Tijani (VMware)

Kubernetes v1.24 引入了对节点非体面关闭（Non-Graceful Node Shutdown）的 Alpha 支持。此特性允许有状态工作负载在原节点关闭或处于不可恢复状态（如硬件故障或操作系统损坏）后，故障转移到不同的节点。

Kubernetes 1.24: 防止未经授权的卷模式转换

Wed, 18 May 2022 00:00:00 +0000

作者： Raunak Pradip Shah (Mirantis)

Kubernetes v1.24 引入了一个新的 alpha 级特性，可以防止未经授权的用户修改基于 Kubernetes 集群中已有的 VolumeSnapshot 创建的 PersistentVolumeClaim 的卷模式。

问题

卷模式确定卷是格式化为文件系统还是显示为原始块设备。

Kubernetes 1.24: 卷填充器功能进入 Beta 阶段

Mon, 16 May 2022 00:00:00 +0000

作者： Ben Swartzlander (NetApp)

卷填充器功能现在已经经历两个发行版本并进入 Beta 阶段！在 Kubernetes v1.24 中 AnyVolumeDataSource 特性门控默认被启用。这意味着用户可以指定任何自定义资源作为 PVC 的数据源。

Kubernetes 1.24：gRPC 容器探针功能进入 Beta 阶段

Fri, 13 May 2022 00:00:00 +0000

作者：Sergey Kanzhelev (Google)

译者：Xiaoyang Zhang（Huawei）

在 Kubernetes 1.24 中，gRPC 探针（probe）功能进入了 beta 阶段，默认情况下可用。现在，你可以为 gRPC 应用程序配置启动、活跃和就绪探测，而无需公开任何 HTTP 端点，也不需要可执行文件。Kubernetes 可以通过 gRPC 直接连接到你的工作负载并查询其状态。

Kubernetes 1.24 版本中存储容量跟踪特性进入 GA 阶段

Fri, 06 May 2022 00:00:00 +0000

作者: Patrick Ohly（Intel）

在 Kubernetes v1.24 版本中，存储容量跟踪已经成为一项正式发布的功能。

已经解决的问题

如上一篇关于此功能的博文中所详细介绍的，存储容量跟踪允许 CSI 驱动程序发布有关剩余容量的信息。当 Pod 仍然有需要配置的卷时， kube-scheduler 使用该信息为 Pod 选择合适的节点。

Kubernetes 1.24：卷扩充现在成为稳定功能

Thu, 05 May 2022 00:00:00 +0000

作者： Hemant Kumar (Red Hat)

Dockershim：历史背景

Tue, 03 May 2022 00:00:00 +0000

作者： Kat Cosgrove

Kubernetes 1.24: 观星者

Tue, 03 May 2022 00:00:00 +0000

作者: Kubernetes 1.24 发布团队

Frontiers, fsGroups and frogs: Kubernetes 1.23 发布采访

Fri, 29 Apr 2022 00:00:00 +0000

作者: Craig Box (Google)

举办每周一次的来自 Google 的 Kubernetes 播客的亮点之一是与每个新 Kubernetes 版本的发布经理交谈。发布团队不断刷新。许多人从小型文档修复开始，逐步晋升为影子角色，然后最终领导发布。

在 Ingress-NGINX v1.2.0 中提高安全标准

Thu, 28 Apr 2022 00:00:00 +0000

作者： Ricardo Katz (VMware), James Strong (Chainguard)

Ingress 可能是 Kubernetes 最容易受攻击的组件之一。 Ingress 通常定义一个 HTTP 反向代理，暴露在互联网上，包含多个网站，并具有对 Kubernetes API 的一些特权访问（例如读取与 TLS 证书及其私钥相关的 Secret）。

Kubernetes 1.24 中的移除和弃用

Thu, 07 Apr 2022 00:00:00 +0000

作者：Mickey Boxell (Oracle)

随着 Kubernetes 的发展，一些特性和 API 会被定期重检和移除。新特性可能会提供替代或改进的方法，来解决现有的问题，从而激励团队移除旧的方法。

我们希望确保你了解 Kubernetes 1.24 版本的变化。该版本将弃用一些（测试版/beta）API，转而支持相同 API 的稳定版本。Kubernetes 1.24 版本的主要变化是移除 Dockershim。这将在下面讨论，并将在发布时更深入地探讨。要提前了解 Kubernetes 1.24 中的更改，请查看正在更新中的 CHANGELOG。

你的集群准备好使用 v1.24 版本了吗？

Thu, 31 Mar 2022 00:00:00 +0000

作者: Kat Cosgrove

早在 2020 年 12 月，Kubernetes 就宣布弃用 Dockershim。在 Kubernetes 中，dockershim 是一个软件 shim，它允许你将整个 Docker 引擎用作 Kubernetes 中的容器运行时。在即将发布的 v1.24 版本中，我们将移除 Dockershim - 在宣布弃用之后到彻底移除这段时间内，我们至少预留了一年的时间继续支持此功能，这符合相关的项目策略。如果你是集群操作员，则该指南包含你在此版本中需要了解的实际情况。另外还包括你需要做些什么来确保你的集群不会崩溃！

认识我们的贡献者 - 亚太地区（澳大利亚-新西兰地区）

Wed, 16 Mar 2022 00:00:00 +0000

作者和采访者： Anubhav Vardhan、 Atharva Shinde、 Avinesh Tripathi、 Brad McCoy、 Debabrata Panigrahi、 Jayesh Srivastava、 Kunal Verma、 Pranshu Srivastava、 Priyanka Saggu、 Purneswar Prasad、 Vedant Kakde

大家好👋

欢迎来到亚太地区的”认识我们的贡献者”博文系列第二期。

更新：移除 Dockershim 的常见问题

Thu, 17 Feb 2022 00:00:00 +0000

本文是针对 2020 年末发布的弃用 Dockershim 的常见问题的博客更新。本文包括 Kubernetes v1.24 版本的更新。

本文介绍了一些关于从 Kubernetes 中移除 dockershim 的常见问题。该移除最初是作为 Kubernetes v1.20 版本的一部分宣布的。 Kubernetes 在 v1.24 版移除了 dockershim。

SIG Node CI 子项目庆祝测试改进两周年

Wed, 16 Feb 2022 00:00:00 +0000

作者： Sergey Kanzhelev (Google), Elana Hashman (Red Hat)

保证 SIG 节点上游代码的可靠性是一项持续的工作，需要许多贡献者在幕后付出大量努力。 Kubernetes、基础操作系统、容器运行时和测试基础架构的频繁发布，导致了一个复杂的矩阵，需要关注和稳定的投资来“保持灯火通明”。2020 年 5 月，Kubernetes Node 特殊兴趣小组（“SIG Node”）为节点相关代码和测试组织了一个新的持续集成（CI）子项目。自成立以来，SIG Node CI 子项目每周举行一次会议，即使一整个小时通常也不足以完成对所有缺陷、测试相关的 PR 和问题的分类，并讨论组内所有相关的正在进行的工作。

关注 SIG Multicluster

Mon, 07 Feb 2022 00:00:00 +0000

作者： Dewan Ahmed (Aiven) 和 Chris Short (AWS)

简介

SIG Multicluster 是专注于如何拓展 Kubernetes 的概念并将其用于集群边界之外的 SIG。以往 Kubernetes 资源仅在 Kubernetes Resource Universe (KRU) 这个边界内进行交互，其中 KRU 不是一个实际的 Kubernetes 概念。即使是现在，Kubernetes 集群对自身或其他集群并不真正了解。集群标识符的缺失就是一个例子。随着多云和多集群部署日益普及，SIG Multicluster 所做的工作越来越受到关注。在这篇博客中，来自 Google 的 Jeremy Olmsted-Thompson 和来自 AWS 的 Chris Short 讨论了 SIG Multicluster 正在解决的一些有趣的问题和以及大家如何参与其中。为简洁起见，下文将使用他们两位的首字母 JOT 和 CS。

确保准入控制器的安全

Wed, 19 Jan 2022 00:00:00 +0000

作者: Rory McCune (Aqua Security)

准入控制和认证、授权都是 Kubernetes 安全性的关键部分。 Webhook 准入控制器被广泛用于以多种方式帮助提高 Kubernetes 集群的安全性，包括限制工作负载权限和确保部署到集群的镜像满足组织安全要求。

认识我们的贡献者 - 亚太地区（印度地区）

Mon, 10 Jan 2022 00:00:00 +0000

作者和采访者： Anubhav Vardhan、 Atharva Shinde、 Avinesh Tripathi、 Debabrata Panigrahi、 Kunal Verma、 Pranshu Srivastava、 Pritish Samal、 Purneswar Prasad、 Vedant Kakde

编辑： Priyanka Saggu

大家好 👋

欢迎来到亚太地区的“认识我们的贡献者”博文系列第一期。

Kubernetes 即将移除 Dockershim：承诺和下一步

Fri, 07 Jan 2022 00:00:00 +0000

作者： Sergey Kanzhelev (Google), Jim Angel (Google), Davanum Srinivas (VMware), Shannon Kularathna (Google), Chris Short (AWS), Dawn Chen (Google)

Kubernetes 将在即将发布的 1.24 版本中移除 dockershim。我们很高兴能够通过支持开源容器运行时、支持更小的 kubelet 以及为使用 Kubernetes 的团队提高工程速度来重申我们的社区价值。如果你使用 Docker Engine 作为 Kubernetes 集群的容器运行时，请准备好在 1.24 中迁移！要检查你是否受到影响，请参考检查移除 Dockershim 对你的影响。

Security Profiles Operator v0.4.0 中的新功能

Fri, 17 Dec 2021 00:00:00 +0000

作者: Jakub Hrozek, Juan Antonio Osorio, Paulo Gomes, Sascha Grunert

Security Profiles Operator (SPO) 是一种树外 Kubernetes 增强功能，用于更方便、更便捷地管理 seccomp、 SELinux 和 AppArmor 配置文件。我们很高兴地宣布，我们最近发布了 v0.4.0 的 Operator，其中包含了大量的新功能、缺陷修复和可用性改进。

Kubernetes 1.23: StatefulSet PVC 自动删除 (alpha)

Thu, 16 Dec 2021 00:00:00 +0000

作者: Matthew Cary (谷歌)

Kubernetes v1.23 为 StatefulSets 引入了一个新的 alpha 级策略，用来控制由 StatefulSet 规约模板生成的 PersistentVolumeClaims (PVCs) 的生命周期，用于当删除 StatefulSet 或减少 StatefulSet 中的 Pods 数量时 PVCs 应该被自动删除的场景。

Kubernetes 1.23：树内存储向 CSI 卷迁移工作的进展更新

Fri, 10 Dec 2021 00:00:00 +0000

作者: Jiawei Wang（谷歌）

自 Kubernetes v1.14 引入容器存储接口（Container Storage Interface, CSI）的工作达到 alpha 阶段后，自 v1.17 起，Kubernetes 树内存储插件（in-tree storage plugin）向 CSI 的迁移基础设施已步入 beta 阶段。

Kubernetes 1.23：IPv4/IPv6 双协议栈网络达到 GA

Wed, 08 Dec 2021 00:00:00 +0000

作者: Bridget Kromhout (微软)

“Kubernetes 何时支持 IPv6？” 自从 k8s v1.9 版本中首次添加对 IPv6 的 alpha 支持以来，这个问题的讨论越来越频繁。虽然 Kubernetes 从 v1.18 版本开始就支持纯 IPv6 集群，但当时还无法支持 IPv4 迁移到 IPv6。 IPv4/IPv6 双协议栈网络在 Kubernetes v1.23 版本中进入正式发布（GA）阶段。

公布 2021 年指导委员会选举结果

Mon, 08 Nov 2021 00:00:00 +0000

作者：Kaslin Fields

2021 年指导委员会选举现已完成。 Kubernetes 指导委员会由 7 个席位组成，其中 4 个席位将在 2021 年进行选举。新任委员会成员任期 2 年，所有成员均由 Kubernetes 社区选举产生。

关注 SIG Node

Mon, 27 Sep 2021 00:00:00 +0000

Author: Dewan Ahmed, Red Hat

介绍

在 Kubernetes 中，一个 Node 是你集群中的某台机器。 SIG Node 负责这一非常重要的 Node 组件并支持各种子项目，如 Kubelet, Container Runtime Interface (CRI) 以及其他支持 Pod 和主机资源间交互的子项目。在这篇文章中，我们总结了和 Elana Hashman (EH) & Sergey Kanzhelev (SK) 的对话，是他们带领我们了解作为此 SIG 一份子的各个方面，并分享一些关于其他人如何参与的见解。

更新 NGINX-Ingress 以使用稳定的 Ingress API

Mon, 26 Jul 2021 00:00:00 +0000

作者： James Strong, Ricardo Katz

对于所有 Kubernetes API，一旦它们被正式发布（GA），就有一个创建、维护和最终弃用它们的过程。 networking.k8s.io API 组也不例外。即将发布的 Kubernetes 1.22 版本将移除几个与网络相关的已弃用 API：

聚焦 SIG Usability

Thu, 15 Jul 2021 00:00:00 +0000

说明：

本篇聚焦博客提到的 SIG Usability 已被弃用并且不再活跃。因此，本文中提供的链接和信息可能已失效或不再适用。如果未来社区对该小组重新产生兴趣并有更多成员参与，它有可能会被重新启用。但根据 Kubernetes 社区的政策，截至 2023 年 8 月，该 SIG 已处于非活跃状态。 Kubernetes 项目鼓励你去探索其他 SIG 以及 Kubernetes 官网提供的各类资源，以便及时了解 Kubernetes 的最新进展和功能增强。

卷健康监控的 Alpha 更新

Fri, 16 Apr 2021 00:00:00 +0000

作者： Xing Yang (VMware)

最初在 1.19 中引入的 CSI 卷健康监控功能在 1.21 版本中进行了大规模更新。

为什么要向 Kubernetes 添加卷健康监控？

如果没有卷健康监控，在 PVC 被 Pod 配置和使用后，Kubernetes 将不知道存储系统的底层卷的状态。在 Kubernetes 中配置卷后，底层存储系统可能会发生很多事情。例如，卷可能在 Kubernetes 之外被意外删除、卷所在的磁盘可能发生故障、容量不足、磁盘可能被降级而影响其性能等等。即使卷被挂载到 Pod 上并被应用程序使用，以后也可能会出现诸如读/写 I/O 错误、文件系统损坏、在 Kubernetes 之外被意外卸载卷等问题。当发生这样的事情时，调试和检测根本原因是非常困难的。

弃用 PodSecurityPolicy：过去、现在、未来

Tue, 06 Apr 2021 00:00:00 +0000

作者：Tabitha Sable（Kubernetes SIG Security）

更新：随着 Kubernetes v1.25 的发布，PodSecurityPolicy 已被删除。

你可以在 Kubernetes 1.25 发布说明中阅读有关删除 PodSecurityPolicy 的更多信息。

PodSecurityPolicy (PSP) 在 Kubernetes 1.21 中被弃用。 PSP 日后会被移除，但目前不会改变任何其他内容。在移除之前，PSP 将继续在后续多个版本中完全正常运行。与此同时，我们正在开发 PSP 的替代品，希望可以更轻松、更可持续地覆盖关键用例。

一个编排高可用应用的 Kubernetes 自定义调度器

Mon, 21 Dec 2020 00:00:00 +0000

作者: Chris Seto (Cockroach Labs)

只要你愿意遵守规则，那么在 Kubernetes 上的部署和探索可以是相当愉快的。更多时候，事情会 "顺利进行"。然而，如果一个人对与必须保持存活的鳄鱼一起旅行或者是对必须保持可用的数据库进行扩展有兴趣，情况可能会变得更复杂一点。相较于这个问题，建立自己的飞机或数据库甚至还可能更容易一些。撇开与鳄鱼的旅行不谈，扩展一个高可用的有状态系统也不是一件小事。

Kubernetes 1.20：CSI 驱动程序中的 Pod 身份假扮和短时卷

Fri, 18 Dec 2020 00:00:00 +0000

作者: Shihang Zhang（谷歌）

通常，当 CSI 驱动程序挂载诸如 Secret 和证书之类的凭据时，它必须通过存储提供者的身份认证才能访问这些凭据。然而，对这些凭据的访问是根据 Pod 的身份而不是 CSI 驱动程序的身份来控制的。因此，CSI 驱动程序需要某种方法来取得 Pod 的服务帐户令牌。

Kubernetes 1.20: 最新版本

Tue, 08 Dec 2020 00:00:00 +0000

作者: Kubernetes 1.20 发布团队

我们很高兴地宣布 Kubernetes 1.20 的发布，这是我们 2020 年的第三个也是最后一个版本！此版本包含 42 项增强功能：11 项增强功能已升级到稳定版，15 项增强功能正在进入测试版，16 项增强功能正在进入 Alpha 版。

1.20 发布周期在上一个延长的发布周期之后恢复到 11 周的正常节奏。这是一段时间以来功能最密集的版本之一：Kubernetes 创新周期仍呈上升趋势。此版本具有更多的 Alpha 而非稳定的增强功能，表明云原生生态系统仍有许多需要探索的地方。

别慌: Kubernetes 和 Docker

Wed, 02 Dec 2020 00:00:00 +0000

作者： Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas

更新：Kubernetes 通过 dockershim 对 Docker 的支持现已移除。有关更多信息，请阅读移除 FAQ。你还可以通过专门的 GitHub issue 讨论弃用。

弃用 Dockershim 的常见问题

Wed, 02 Dec 2020 00:00:00 +0000

更新：本文有较新版本。

本文回顾了自 Kubernetes v1.20 版宣布弃用 Dockershim 以来所引发的一些常见问题。关于 Kubernetes kubelets 从容器运行时的角度弃用 Docker 的细节以及这些细节背后的含义，请参考博文别慌: Kubernetes 和 Docker。

为开发指南做贡献

Thu, 01 Oct 2020 00:00:00 +0000

当大多数人想到为一个开源项目做贡献时，我猜想他们可能想到的是贡献代码修改、新功能和错误修复。作为一个软件工程师和一个长期的开源用户和贡献者，这也正是我的想法。虽然我已经在不同的工作流中写了不少文档，但规模庞大的 Kubernetes 社区是一种新型 "客户"。我只是不知道当 Google 要求我和 Lion's Way 的同胞们对 Kubernetes 开发指南进行必要更新时会发生什么。

结构化日志介绍

Fri, 04 Sep 2020 00:00:00 +0000

作者： Marek Siarkowicz（谷歌），Nathan Beach（谷歌）

日志是可观察性的一个重要方面，也是调试的重要工具。但是Kubernetes日志传统上是非结构化的字符串，因此很难进行自动解析，以及任何可靠的后续处理、分析或查询。

在Kubernetes 1.19中，我们添加结构化日志的支持，该日志本身支持（键，值）对和对象引用。我们还更新了许多日志记录调用，以便现在将典型部署中超过99％的日志记录量迁移为结构化格式。

警告: 有用的预警

Thu, 03 Sep 2020 00:00:00 +0000

作者: Jordan Liggitt (Google)

作为 Kubernetes 维护者，我们一直在寻找在保持兼容性的同时提高可用性的方法。在开发功能、分类 Bug、和回答支持问题的过程中，我们积累了有助于 Kubernetes 用户了解的信息。过去，共享这些信息仅限于发布说明、公告电子邮件、文档和博客文章等带外方法。除非有人知道需要寻找这些信息并成功找到它们，否则他们不会从中受益。

Docsy 带来更好的 Docs UX

Mon, 15 Jun 2020 00:00:00 +0000

作者： Zach Corleissen，Cloud Native Computing Foundation

编者注：Zach 是 Kubernetes 文档特别兴趣小组（SIG Docs）的主席之一。

我很高兴地宣布 Kubernetes 网站现在采用了 Docsy Hugo 主题。

Kubernetes 1.18: Fit & Finish

Wed, 25 Mar 2020 00:00:00 +0000

作者: Kubernetes 1.18 发布团队

我们很高兴宣布 Kubernetes 1.18 版本的交付，这是我们 2020 年的第一版！Kubernetes 1.18 包含 38 个增强功能：15 项增强功能已转为稳定版，11 项增强功能处于 beta 阶段，12 项增强功能处于 alpha 阶段。

Kubernetes 1.18 是一个近乎 “完美” 的版本。为了改善 beta 和稳定的特性，已进行了大量工作，以确保用户获得更好的体验。我们在增强现有功能的同时也增加了令人兴奋的新特性，这些有望进一步增强用户体验。

基于 MIPS 架构的 Kubernetes 方案

Wed, 15 Jan 2020 00:00:00 +0000

作者: 石光银，尹东超，展望，江燕，蔡卫卫，高传集，孙思清（浪潮）

背景

MIPS (Microprocessor without Interlocked Pipelined Stages) 是一种采取精简指令集（RISC）的处理器架构 (ISA)，出现于 1981 年，由 MIPS 科技公司开发。如今 MIPS 架构被广泛应用于许多电子产品上。

Kubernetes 1.17：稳定

Mon, 09 Dec 2019 13:00:00 -0800

作者: Kubernetes 1.17发布团队

我们高兴的宣布Kubernetes 1.17版本的交付，它是我们2019年的第四个也是最后一个发布版本。Kubernetes v1.17包含22个增强功能：有14个增强已经逐步稳定(stable)，4个增强功能已经进入公开测试版(beta)，4个增强功能刚刚进入内部测试版(alpha)。

主要的主题

云服务提供商标签基本可用

作为公开测试版特性添加到 v1.2 ，v1.17 中可以看到云提供商标签达到基本可用。

使用 Java 开发一个 Kubernetes controller

Tue, 26 Nov 2019 00:00:00 +0000

作者: Min Kim (蚂蚁金服), Tony Ado (蚂蚁金服)

Kubernetes Java SDK 官方项目最近发布了他们的最新工作，为 Java Kubernetes 开发人员提供一个便捷的 Kubernetes 控制器-构建器 SDK，它有助于轻松开发高级工作负载或系统。

使用 Microk8s 在 Linux 上本地运行 Kubernetes

Tue, 26 Nov 2019 00:00:00 +0000

作者: Ihor Dvoretskyi，开发支持者，云原生计算基金会；Carmine Rimi

本文是关于 Linux 上的本地部署选项系列的第二篇，涵盖了 MicroK8s。Microk8s 是本地部署 Kubernetes 集群的 'click-and-run' 方案，最初由 Ubuntu 的发布者 Canonical 开发。

Kubernetes 文档最终用户调研

Tue, 29 Oct 2019 00:00:00 +0000

Author: Aimee Ukasick and SIG Docs

9月，SIG Docs 进行了第一次关于 Kubernetes 文档的用户调研。我们要感谢 CNCF 的 Kim McMahon 帮助我们创建调查并获取结果。

主要收获

受访者希望能在概念、任务和参考部分得到更多示例代码、更详细的内容和更多图表。

圣迭戈贡献者峰会日程公布！

Thu, 10 Oct 2019 00:00:00 +0000

作者： Josh Berkus (Red Hat), Paris Pittman (Google), Jonas Rosland (VMware)

除了新贡献者研讨会之外，贡献者峰会还安排了许多精彩的会议，这些会议分布在当前五个贡献者内容的会议室中。由于这是一个上游贡献者峰会，并且我们不经常见面，所以作为一个全球分布的团队，这些会议大多是讨论或动手实践，而不仅仅是演示。我们希望大家互相学习，并于他们的开源代码队友玩的开心。

2019 指导委员会选举结果

Thu, 03 Oct 2019 00:00:00 +0000

作者：Bob Killen (University of Michigan), Jorge Castro (VMware), Brian Grant (Google), and Ihor Dvoretskyi (CNCF)

2019 指导委员会选举是 Kubernetes 项目的重要里程碑。最初的自助委员会正逐步退休，现在该委员会已缩减到最后分配的 7 个席位。指导委员会的所有成员现在都由 Kubernetes 社区选举产生。

San Diego 贡献者峰会开放注册！

Tue, 24 Sep 2019 00:00:00 +0000

作者： Paris Pittman (Google), Jeffrey Sica (Red Hat), Jonas Rosland (VMware)

2019 San Diego 贡献者峰会活动页面在创纪录的时间内，新贡献者研讨会 活动已满员！

机器可以完成这项工作，一个关于 kubernetes 测试、CI 和自动化贡献者体验的故事

Thu, 29 Aug 2019 00:00:00 +0000

作者：Aaron Crickenberger（谷歌）和 Benjamin Elder（谷歌）

”大型项目有很多不那么令人兴奋，但却很辛苦的工作。比起辛苦工作，我们更重视把时间花在自动化重复性工作上，如果这项工作无法实现自动化，我们的文化就是承认并奖励所有类型的贡献。然而，英雄主义是不可持续的。“ - Kubernetes Community Values

OPA Gatekeeper：Kubernetes 的策略和管理

Tue, 06 Aug 2019 00:00:00 +0000

作者： Rita Zhang (Microsoft), Max Smythe (Google), Craig Hooper (Commonwealth Bank AU), Tim Hinrichs (Styra), Lachie Evenson (Microsoft), Torin Sandall (Styra)

可以从项目 Open Policy Agent Gatekeeper 中获得帮助，在 Kubernetes 环境下实施策略并加强治理。在本文中，我们将逐步介绍该项目的目标，历史和当前状态。

欢迎参加在上海举行的贡献者峰会

Tue, 11 Jun 2019 00:00:00 +0000

Author: Josh Berkus (Red Hat)

![贡献者小组讨论掠影，摄于 2018 年上海贡献者峰会，作者 Josh Berkus, 许可证 CC-BY 4.0](/images/blog/2019- 06-11-contributor-summit-shanghai/panel.png)

连续第二年，我们将在 KubeCon China 之前举行一天的贡献者峰会。不管您是否已经是一名 Kubernetes 贡献者，还是想要加入社区队伍，贡献一份力量，都请考虑注册参加这次活动。这次峰会将于六月 24 号，在上海世博中心（和 KubeCon 的举办地点相同）举行，一天的活动将包含“现有贡献者活动”，以及“新贡献者工作坊”和“文档小组活动”。

壮大我们的贡献者研讨会

Tue, 14 May 2019 00:00:00 +0000

作者: Guinevere Saenger (GitHub) 和 Paris Pittman (Google)（谷歌）

tl;dr - 与我们一起了解贡献者社区，并获得你的第一份 PR ! 我们在[巴塞罗那][欧洲]有空位（登记在5月15号周三结束，所以抓住这次机会！）并且在[上海][中国]有即将到来的峰会。

如何参与 Kubernetes 文档的本地化工作

Fri, 26 Apr 2019 00:00:00 +0000

作者: Zach Corleissen（Linux 基金会）

使用 Kubernetes 设备插件和 RuntimeClass 在 Ingress 控制器中实现硬件加速 SSL/TLS 终止

Wed, 24 Apr 2019 00:00:00 +0000

作者： Mikko Ylinen (Intel)

译者： pegasas

摘要

Kubernetes Ingress 是在集群服务与集群外部世界建立连接的一种方法。为了正确地将流量路由到服务后端，集群需要一个 Ingress 控制器。Ingress 控制器负责根据 Ingress API 对象的信息设置目标到正确的后端。实际流量通过代理服务器路由，代理服务器负责诸如负载均衡和 SSL/TLS （稍后的“SSL”指 SSL 或 TLS）终止等任务。由于涉及加密操作，SSL 终止是一个 CPU 密集型操作。为了从 CPU 中分载一些 CPU 密集型工作，基于 OpenSSL 的代理服务器可以利用 OpenSSL Engine API 和专用加密硬件的优势。这将为其他事情释放 CPU 周期，并提高代理服务器的总体吞吐量。

Kubernetes 1.14 稳定性改进中的进程ID限制

Mon, 15 Apr 2019 00:00:00 +0000

作者: Derek Carr

Raw Block Volume 支持进入 Beta

Thu, 07 Mar 2019 00:00:00 +0000

作者： Ben Swartzlander (NetApp), Saad Ali (Google)

Kubernetes v1.13 中对原生数据块卷（Raw Block Volume）的支持进入 Beta 阶段。此功能允许将持久卷作为块设备而不是作为已挂载的文件系统暴露在容器内部。

什么是块设备？

块设备允许对固定大小的块中的数据进行随机访问。硬盘驱动器、SSD 和 CD-ROM 驱动器都是块设备的例子。

新贡献者工作坊上海站

Wed, 05 Dec 2018 00:00:00 +0000

作者: Josh Berkus (红帽), Yang Li (The Plant), Puja Abbassi (Giant Swarm), XiangPeng Zhao (中兴通讯)

KubeCon 上海站新贡献者峰会与会者，摄影：Jerry Zhang

Kubernetes 文档更新，国际版

Thu, 08 Nov 2018 00:00:00 +0000

作者：Zach Corleissen （Linux 基金会）

作为文档特别兴趣小组（SIG Docs）的联合主席，我很高兴能与大家分享 Kubernetes 文档在本地化（l10n）方面所拥有的一个完全成熟的工作流。

丰富的缩写

L10n 是 localization 的缩写。

I18n 是 internationalization 的缩写。

Kubernetes 2018 年北美贡献者峰会

Tue, 16 Oct 2018 00:00:00 +0000

作者：

Bob Killen（密歇根大学） Sahdev Zala（IBM）， Ihor Dvoretskyi（CNCF）

2018 年北美 Kubernetes 贡献者峰会将在西雅图 KubeCon + CloudNativeCon 会议之前举办，这将是迄今为止规模最大的一次盛会。

这是一个将新老贡献者聚集在一起，面对面交流和分享的活动；并为现有的贡献者提供一个机会，帮助塑造社区发展的未来。它为新的社区成员提供了一个学习、探索和实践贡献工作流程的良好空间。

2018 年督导委员会选举结果

Mon, 15 Oct 2018 00:00:00 +0000

作者: Jorge Castro (Heptio), Ihor Dvoretskyi (CNCF), Paris Pittman (Google)

结果

Kubernetes 督导委员会选举现已完成，以下候选人获得了立即开始的两年任期：

Aaron Crickenberger, Google, @spiffxp
Davanum Srinivas, Huawei, @dims
Tim St. Clair, Heptio, @timothysc

十分感谢！

督导委员会荣誉退休成员 Quinton Hoole，表扬他在过去一年为社区所作的贡献。我们期待着
参加竞选的候选人。愿我们永远拥有一群强大的人，他们希望在每一次选举中都能像你们一样推动社区向前发展。
共计 307 名选民参与投票。
本次选举由康奈尔大学主办 CIVS！

加入督导委员会

你可以关注督导委员会的任务清单，并通过向他们的代码仓库提交 issue 或 PR 的方式来参与。他们也会在UTC 时间每周三晚 8 点举行会议，并定期与我们的贡献者见面。

Kubernetes 中的拓扑感知数据卷供应

Thu, 11 Oct 2018 00:00:00 +0000

作者: Michelle Au（谷歌）

通过提供拓扑感知动态卷供应功能，具有持久卷的多区域集群体验在 Kubernetes 1.12 中得到了改进。此功能使得 Kubernetes 在动态供应卷时能做出明智的决策，方法是从调度器获得为 Pod 提供数据卷的最佳位置。在多区域集群环境，这意味着数据卷能够在满足你的 Pod 运行需要的合适的区域被供应，从而允许你跨故障域轻松部署和扩展有状态工作负载，从而提供高可用性和容错能力。

Kubernetes v1.12: RuntimeClass 简介

Wed, 10 Oct 2018 00:00:00 +0000

作者: Tim Allclair (Google)

Kubernetes 最初是为了支持在 Linux 主机上运行本机应用程序的 Docker 容器而创建的。从 Kubernetes 1.3 中的 rkt 开始，更多的运行时间开始涌现，这导致了容器运行时接口（Container Runtime Interface）（CRI）的开发。从那时起，备用运行时集合越来越大：为了加强工作负载隔离，Kata Containers 和 gVisor 等项目被发起，并且 Kubernetes 对 Windows 的支持正在稳步发展。

KubeDirector：在 Kubernetes 上运行复杂状态应用程序的简单方法

Wed, 03 Oct 2018 00:00:00 +0000

作者：Thomas Phelan（BlueData）

KubeDirector 是一个开源项目，旨在简化在 Kubernetes 上运行复杂的有状态扩展应用程序集群。KubeDirector 使用自定义资源定义（CRD）框架构建，并利用了本地 Kubernetes API 扩展和设计哲学。这支持与 Kubernetes 用户/资源管理以及现有客户端和工具的透明集成。

在 Kubernetes 上对 gRPC 服务器进行健康检查

Mon, 01 Oct 2018 00:00:00 +0000

作者： Ahmet Alp Balkan (Google)

更新（2021 年 12 月）： “Kubernetes 从 v1.23 开始具有内置 gRPC 健康探测。了解更多信息，请参阅配置存活探针、就绪探针和启动探针。本文最初是为有关实现相同任务的外部工具所写。”

使用 CSI 和 Kubernetes 实现卷的动态扩容

Thu, 02 Aug 2018 00:00:00 +0000

作者：Orain Xiong（联合创始人, WoquTech）

Kubernetes 本身有一个非常强大的存储子系统，涵盖了相当广泛的用例。而当我们计划使用 Kubernetes 构建产品级关系型数据库平台时，我们面临一个巨大的挑战：提供存储。本文介绍了如何扩展最新的 Container Storage Interface 0.2.0 和与 Kubernetes 集成，并演示了卷动态扩容的基本方面。

使用 Kubernetes 调整 PersistentVolume 的大小

Thu, 12 Jul 2018 00:00:00 +0000

作者: Hemant Kumar (Red Hat)

编者注：这篇博客是深度文章系列的一部分，这个系列介绍了 Kubernetes 1.11 中的新增特性

动态 Kubelet 配置

Wed, 11 Jul 2018 00:00:00 +0000

作者: Michael Taufen (Google)

编者注：在 1.22 版本弃用后，该功能已在 1.24 版本中删除。

编者注：这篇文章是一系列深度文章的一部分，这个系列介绍了 Kubernetes 1.11 中的新增功能

为什么要进行动态 Kubelet 配置？

Kubernetes 提供了以 API 为中心的工具，可显着改善用于管理应用程序和基础架构的工作流程。但是，在大多数的 Kubernetes 安装中，kubelet 在每个主机上作为本机进程运行，因此未被标准 Kubernetes API 覆盖。

用于 Kubernetes 集群 DNS 的 CoreDNS GA 正式发布

Tue, 10 Jul 2018 00:00:00 +0000

作者：John Belamaric (Infoblox)

**编者注：这篇文章是系列深度文章中的一篇，介绍了 Kubernetes 1.11 新增的功能

介绍

在 Kubernetes 1.11 中，CoreDNS 已经达到基于 DNS 服务发现的 General Availability (GA)，可以替代 kube-dns 插件。这意味着 CoreDNS 会作为即将发布的安装工具的选项之一上线。实际上，从 Kubernetes 1.11 开始，kubeadm 团队选择将它设为默认选项。

基于 IPVS 的集群内部负载均衡

Mon, 09 Jul 2018 00:00:00 +0000

作者: Jun Du(华为), Haibin Xie(华为), Wei Liang(华为)

注意: 这篇文章出自系列深度文章介绍 Kubernetes 1.11 的新特性

介绍

Airflow 在 Kubernetes 中的使用（第一部分）：一种不同的操作器

Thu, 28 Jun 2018 00:00:00 +0000

作者: Daniel Imberman (Bloomberg LP)

介绍

作为 Bloomberg 持续致力于开发 Kubernetes 生态系统的一部分，我们很高兴能够宣布 Kubernetes Airflow Operator 的发布; Apache Airflow的一种机制，一种流行的工作流程编排框架，使用 Kubernetes API 可以在本机启动任意的 Kubernetes Pod。

Kubernetes 的动态 Ingress

Thu, 07 Jun 2018 00:00:00 +0000

Kubernetes 可以轻松部署由许多微服务组成的应用程序，但这种架构的关键挑战之一是动态地将流量路由到这些服务中的每一个。一种方法是使用 Ambassador，一个基于 Envoy Proxy 构建的 Kubernetes 原生开源 API 网关。 Ambassador 专为动态环境而设计，这类环境中的服务可能被频繁添加或删除。

Kubernetes 这四年

Wed, 06 Jun 2018 00:00:00 +0000

作者：Joe Beda（Heptio 首席技术官兼创始人）

2014 年 6 月 6 日，我检查了 Kubernetes 公共代码库的第一次 commit 。许多人会认为这是故事开始的地方。这难道不是一切开始的地方吗？但这的确不能把整个过程说清楚。

向 Discuss Kubernetes 问好

Wed, 30 May 2018 00:00:00 +0000

作者: Jorge Castro (Heptio)

就一个超过 35,000 人的全球性社区而言，参与其中时沟通是非常关键的。跟踪 Kubernetes 社区中的所有内容可能是一项艰巨的任务。一方面，我们有官方资源，如 Stack Overflow，GitHub 和邮件列表，另一方面，我们有更多瞬时性的资源，如 Slack，你可以加入进去、与某人聊天然后各走各路。

在 Kubernetes 上开发

Tue, 01 May 2018 00:00:00 +0000

作者： Michael Hausenblas (Red Hat), Ilya Dmitrichenko (Weaveworks)

您将如何开发一个 Kubernetes 应用？也就是说，您如何编写并测试一个要在 Kubernetes 上运行的应用程序？本文将重点介绍在独自开发或者团队协作中，您可能希望了解到的为了成功编写 Kubernetes 应用程序而需面临的挑战，工具和方法。

Kubernetes 社区 - 2017 年开源排行榜榜首

Wed, 25 Apr 2018 00:00:00 +0000

对于 Kubernetes 来说，2017 年是丰收的一年，GitHub的最新 Octoverse 报告说明了该项目获得了多少关注。

“基于容器的应用程序设计原理”

Thu, 15 Mar 2018 00:00:00 +0000

如今，可以将几乎所有应用程序放入容器中并运行它。但是，创建云原生应用程序（由 Kubernetes 等云原生平台自动有效地编排的容器化应用程序）需要付出额外的努力。云原生应用程序会预期失败；它们可以可靠的运行和扩展，即使基础架构出现故障。为了提供这样的功能，像 Kubernetes 这样的云原生平台对应用程序施加了一系列约定和约束。这些合同确保运行的应用程序符合某些约束条件，并允许平台自动执行应用程序管理。

Kubernetes 1.9 对 Windows Server 容器提供 Beta 版本支持

Tue, 09 Jan 2018 00:00:00 +0000

随着 Kubernetes v1.9 的发布，我们确保所有人在任何地方都能正常运行 Kubernetes 的使命前进了一大步。我们的 Beta 版本对 Windows Server 的支持进行了升级，并且在 Kubernetes 和 Windows 平台上都提供了持续的功能改进。为了在 Kubernetes 上运行许多特定于 Windows 的应用程序和工作负载，SIG-Windows 自2016年3月以来一直在努力，大大扩展了 Kubernetes 的实现场景和企业适用范围。

Kubernetes 中自动缩放

Fri, 17 Nov 2017 00:00:00 +0000

Kubernetes 允许开发人员根据当前的流量和负载自动调整集群大小和 pod 副本的数量。这些调整减少了未使用节点的数量，节省了资金和资源。在这次演讲中，谷歌的 Marcin Wielgus 将带领您了解 Kubernetes 中 pod 和 node 自动调焦的当前状态：它是如何工作的，以及如何使用它，包括在生产应用程序中部署的最佳实践。

Kubernetes 1.8 的五天

Tue, 24 Oct 2017 00:00:00 +0000

Kubernetes 1.8 已经推出，数百名贡献者在这个最新版本中推出了成千上万的提交。

社区已经有超过 66,000 个提交在主仓库，并在主仓库之外继续快速增长，这标志着该项目日益成熟和稳定。仅 v1.7.0 到 v1.8.0，社区就记录了所有仓库的超过 120,000 次提交和 17839 次提交。

Kubernetes 社区指导委员会选举结果

Thu, 05 Oct 2017 00:00:00 +0000

自 2015 年 OSCON 发布 Kubernetes 1.0 以来，大家一直在共同努力，在 Kubernetes 社区中共同分享领导力和责任。

在 Brandon Philips、Brendan Burns、Brian Grant、Clayton Coleman、Joe Beda、Sarah Novotny 和 Tim Hockin 组成的自举治理委员会的工作下 - 代表 5 家不同公司的长期领导者，他们对 Kubernetes 生态系统进行了大量的人才投资和努力 - 编写了初始的指导委员会章程，并发起了一次社区选举，以选举 Kubernetes 指导委员会成员。

使用 Kubernetes Pet Sets 和 Datera Elastic Data Fabric 的 FlexVolume 扩展有状态的应用程序

Mon, 29 Aug 2016 00:00:00 +0000

编者注：今天的邀请帖子来自 Datera 公司的软件架构师 Shailesh Mittal 和高级产品总监 Ashok Rajagopalan，介绍在 Datera Elastic Data Fabric 上用 Kubernetes 配置状态应用程序。

SIG Apps: 为 Kubernetes 构建应用并在 Kubernetes 中进行运维

Tue, 16 Aug 2016 00:00:00 +0000

编者注：这篇文章由 Kubernetes SIG-Apps 团队撰写，分享他们如何关注在 Kubernetes 中运行应用的开发者和 devops 经验。

Kubernetes 生日快乐。哦，这是你要去的地方！

Thu, 21 Jul 2016 00:00:00 +0000

编者按，今天的嘉宾帖子来自一位独立的 kubernetes 撰稿人 Justin Santa Barbara，分享了他对项目从一开始到未来发展的思考。

将端到端的 Kubernetes 测试引入 Azure （第二部分）

Mon, 18 Jul 2016 00:00:00 +0000

作者标注：今天的邀请帖子是 Travis Newhouse 的系列中的第二部分，他是 AppFormix 的首席架构师，这篇文章介绍了他们对 Kubernetes 的贡献。

历史上，Kubernetes 测试一直由谷歌托管，在谷歌计算引擎 (GCE) 和谷歌容器引擎 (GKE) 上运行端到端测试。实际上，提交队列的选通检查是在这些测试平台上执行测试的子集。联合测试旨在通过使组织托管各种平台的测试作业并贡献测试结果，从而让 Kubernetes 项目受益来扩大测试范围。谷歌和 SIG-Testing 的 Kubernetes 测试小组成员已经创建了一个 Kubernetes 测试历史记录仪表板，可以发布所有联合测试作业（包括谷歌托管的作业）的全部结果。

Dashboard - Kubernetes 的全功能 Web 界面

Fri, 15 Jul 2016 00:00:00 +0000

编者按：这篇文章是一系列深入的文章中关于Kubernetes 1.3的新内容的一部分 Kubernetes Dashboard是一个旨在为 Kubernetes 世界带来通用监控和操作 Web 界面的项目。三个月前，我们发布第一个面向生产的版本，从那时起 dashboard 已经做了大量的改进。在一个 UI 中，您可以在不离开浏览器的情况下，与 Kubernetes 集群执行大多数可能的交互。这篇博客文章分解了最新版本中引入的新功能，并概述了未来的路线图。

Citrix + Kubernetes = 全垒打

Thu, 14 Jul 2016 00:00:00 +0000

编者按：今天的客座文章来自 Citrix Systems 的产品管理总监 Mikko Disini，他分享了他们在 Kubernetes 集成上的合作经验。 _

技术合作就像体育运动。如果你能像一个团队一样合作，你就能在最后关头取得胜利。这就是我们对谷歌云平台团队的经验。

容器中运行有状态的应用！？ Kubernetes 1.3 说 “是！”

Wed, 13 Jul 2016 00:00:00 +0000

编者注：今天的来宾帖子来自 Diamanti 产品副总裁 Mark Balch，他将分享有关他们对 Kubernetes 所做的贡献的更多信息。

祝贺 Kubernetes 社区发布了另一个有价值的版本。专注于有状态应用程序和联邦集群是我对 1.3 如此兴奋的两个原因。 Kubernetes 对有状态应用程序（例如 Cassandra、Kafka 和 MongoDB）的支持至关重要。重要服务依赖于数据库、键值存储、消息队列等。此外，随着应用程序的发展为全球数百万用户提供服务，仅依靠一个数据中心或容器集群将无法正常工作。联邦集群允许用户跨多个集群和数据中心部署应用程序，以实现规模和弹性。

CoreOS Fest 2016: CoreOS 和 Kubernetes 在柏林（和旧金山）社区见面会

Tue, 03 May 2016 00:00:00 +0000

CoreOS Fest 2016 将汇集容器和开源分布式系统社区，其中包括 Kubernetes 领域的许多思想领袖。这是第二次年度 CoreOS 社区会议，于5月9日至10日在柏林首次举行。 CoreOS 相信 Kubernetes 是提供 GIFEE（适用于所有人的 Google 的基础架构）服务的合适的容器编排组件。

SIG-ClusterOps: 提升 Kubernetes 集群的可操作性和互操作性

Tue, 19 Apr 2016 00:00:00 +0000

编者注：本周我们将推出 Kubernetes 特殊兴趣小组；今天的帖子由 SIG-ClusterOps 团队负责，其任务是促进 Kubernetes 集群的可操作性和互操作性 -- 倾听，帮助和升级。

我们认为 Kubernetes 是大规模运行应用程序的绝佳方法！不幸的是，存在一个引导问题：我们需要良好的方法来围绕 Kubernetes 构建安全可靠的扩展环境。虽然平台管理的某些部分利用了平台（很酷！），这有一些基本的操作主题需要解决，还有一些问题（例如升级和一致性）需要回答。

“SIG-Networking：1.3 版本引入 Kubernetes 网络策略 API”

Mon, 18 Apr 2016 00:00:00 +0000

编者注：本周我们将推出 Kubernetes 特殊兴趣小组、 Network-SIG 小组今天的帖子描述了 1.3 版中的网络策略 API-安全，隔离和多租户策略。

自去年下半年以来，Kubernetes SIG-Networking 一直在定期开会，致力于将网络策略引入 Kubernetes，我们开始看到这个努力的结果。

在 Rancher 中添加对 Kuernetes 的支持

Fri, 08 Apr 2016 00:00:00 +0000

今天的来宾帖子由 Rancher Labs（用于管理容器的开源软件平台）的首席架构师 Darren Shepherd 撰写。

在过去的一年中，我们看到希望在其软件开发和IT组织中利用容器的公司数量激增。为了实现这一目标，组织一直在研究如何构建集中式的容器管理功能，该功能将使用户可以轻松访问容器，同时集中管理IT组织的可见性和控制力。 2014年，我们启动了开源 Rancher 项目，通过构建容器管理平台来解决此问题。

KubeCon EU 2016：伦敦 Kubernetes 社区

Wed, 24 Feb 2016 00:00:00 +0000

KubeCon EU 2016 是首届欧洲 Kubernetes 社区会议，紧随 2015 年 11 月召开的北美会议。KubeCon 致力于为 Kubernetes 爱好者、产品用户和周围的生态系统提供教育和社区参与。

快来加入我们在伦敦，与 Kubernetes 社区的数百人一起出去，体验各种深入的技术专家讲座和用例。

Kubernetes 社区会议记录 - 20160218

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

2月18号 - kmachine 演示、SIG clusterops 成立、新的 k8s.io 网站预览、1.2 版本更新和 1.3 版本计划

Kubernetes 贡献社区会议大多在星期四的 10:00 召开，通过视频会议讨论项目现有情况。这里是最近一次会议的笔记。

Kubernetes 社区会议记录 - 20160204

Tue, 09 Feb 2016 00:00:00 +0000

2 月 4 日 - rkt 演示（祝贺 1.0 版本，CoreOS！），eBay 将 k8s 放在 Openstack 上并认为 Openstack 在 k8s，SIG 和片状测试激增方面取得了进展。

Kubernetes 贡献社区在每周四 10:00 PT 开会,通过视频会议讨论项目状态。以下是最近一次会议的笔记。

容器世界现状，2016 年 1 月

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

新年伊始，我们进行了一项调查，以评估容器世界的现状。我们已经准备好发送 2 月版但在此之前，让我们从 119 条回复中看一下 1 月的数据（感谢您的参与！）。

Kubernetes 社区会议记录 - 20160114

Thu, 28 Jan 2016 00:00:00 +0000

1 月 14 日 - RackN 演示、测试问题和 KubeCon EU CFP。

记录者：Joe Beda

演示：在 Metal，AWS 和其他平台上使用 Digital Rebar 自动化部署，来自 RackN 的 Rob Hirschfeld 和 Greg Althaus。

为什么 Kubernetes 不用 libnetwork

Thu, 14 Jan 2016 00:00:00 +0000

在 1.0 版本发布之前，Kubernetes 已经有了一个非常基础的网络插件形式-大约在引入 Docker’s libnetwork 和 Container Network Model (CNM) 的时候。与 libnetwork 不同，Kubernetes 插件系统仍然保留它的 'alpha' 名称。现在 Docker 的网络插件支持已经发布并得到支持，我们发现一个明显的问题是 Kubernetes 尚未采用它。毕竟，供应商几乎肯定会为 Docker 编写插件-我们最好还是用相同的驱动程序，对吧？

Kubernetes 和 Docker 简单的 leader election

Mon, 11 Jan 2016 00:00:00 +0000

概述

Kubernetes 简化了集群上运行的服务的部署和操作管理。但是，它也简化了这些服务的发展。在本文中，我们将看到如何使用 Kubernetes 在分布式应用程序中轻松地执行 leader election。分布式应用程序通常为了可靠性和可伸缩性而复制服务的任务，但通常需要指定其中一个副本作为负责所有副本之间协调的负责人。

使用 Puppet 管理 Kubernetes Pod、Service 和 Replication Controller

Thu, 17 Dec 2015 00:00:00 +0000

今天的嘉宾帖子是由 IT 自动化领域的领导者 Puppet Labs 的高级软件工程师 Gareth Rushgrove 撰写的。Gareth告诉我们一个新的 Puppet 模块，它帮助管理 Kubernetes 中的资源。

Kubernetes 1.1 性能升级，工具改进和社区不断壮大

Mon, 09 Nov 2015 00:00:00 +0000

自从 Kubernetes 1.0 在七月发布以来，我们已经看到大量公司采用建立分布式系统来管理其容器集群。我们也对帮助 Kubernetes 社区变得更好，迅速发展的人感到钦佩。我们已经看到诸如 CoreOS 的 Tectonic 和 RedHat Atomic Host 之类的商业产品应运而生，用以提供 Kubernetes 的部署和支持。一个不断发展的生态系统增加了 Kubernetes 的支持，包括 Sysdig 和 Project Calico 等工具供应商。

Kubernetes 社区每周环聊笔记——2015 年 7 月 31 日

Tue, 04 Aug 2015 00:00:00 +0000

每周，Kubernetes 贡献社区都会通过Google 环聊虚拟开会。我们希望任何有兴趣的人都知道本论坛讨论的内容。

这是今天会议的笔记：

私有镜像仓库演示 - Muhammed

宣布首个Kubernetes企业培训课程

Wed, 08 Jul 2015 00:00:00 +0000

在谷歌，我们依赖 Linux 容器应用程序去运行我们的核心基础架构。所有服务，从搜索引擎到Gmail服务，都运行在容器中。事实上，我们非常喜欢容器，甚至我们的谷歌云计算引擎虚拟机也运行在容器上！由于容器对于我们的业务至关重要，我们已经与社区合作开发许多基本的容器技术（从 cgroups 到 Docker 的 LibContainer）,甚至决定去构建谷歌的下一代开源容器调度技术，Kubernetes。

幻灯片：Kubernetes 集群管理，爱丁堡大学演讲

Fri, 26 Jun 2015 00:00:00 +0000

2015年6月5日星期五，我在爱丁堡大学给普通听众做了一个演讲，题目是使用 Kubernetes 进行集群管理。这次演讲包括一个带有 Kibana 前端 UI 的音乐存储系统的例子，以及一个基于 Elasticsearch 的后端，该后端有助于生成具体的概念，如 pods、复制控制器和服务。

OpenStack 上的 Kubernetes

Tue, 19 May 2015 00:00:00 +0000

今天，OpenStack 基金会通过在其社区应用程序目录中包含 Kubernetes，使您更容易在 OpenStack 云上部署和管理 Docker 容器集群。今天在温哥华 OpenStack 峰会上的主题演讲中，OpenStack 基金会的首席运营官：Mark Collier 和 Mirantis 产品线经理 Craig Peters 通过利用 OpenStack 云中已经存在的计算、存储、网络和标识系统，在几秒钟内启动了 Kubernetes 集群，展示了社区应用程序目录的工作流。

Kubernetes 社区每周聚会笔记- 2015年5月1日

Mon, 11 May 2015 00:00:00 +0000

每个星期，Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。

简单的滚动更新 - Brendan

通过 RKT 对 Kubernetes 的 AppC 支持

Mon, 04 May 2015 00:00:00 +0000

我们最近接受了对 Kubernetes 项目的拉取请求，以增加对 Kubernetes 社区的应用程序支持。 AppC 是由 CoreOS 发起的新的开放容器规范，并通过 CoreOS rkt 容器运行时受到支持。

Kubernetes 社区每周聚会笔记- 2015年4月24日

Thu, 30 Apr 2015 00:00:00 +0000

每个星期，Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。

日程安排：

Flocker 和 Kubernetes 集成演示

笔记：

Borg: Kubernetes 的前身

Thu, 23 Apr 2015 00:00:00 +0000

十多年来，谷歌一直在生产中运行容器化工作负载。无论是像网络前端和有状态服务器之类的工作，像 Bigtable 和 Spanner一样的基础架构系统，或是像 MapReduce 和 Millwheel一样的批处理框架， Google 的几乎一切都是以容器的方式运行的。今天，我们揭开了 Borg 的面纱，Google 传闻已久的面向容器的内部集群管理系统，并在学术计算机系统会议 Eurosys 上发布了详细信息。你可以在此处找到论文。

Kubernetes 社区每周聚会笔记- 2015年4月17日

Fri, 17 Apr 2015 00:00:00 +0000

每个星期，Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。

议程

Kubernetes Release: 0.15.0

Thu, 16 Apr 2015 00:00:00 +0000

Release 说明：

启用 1beta3 API 并将其设置为默认 API 版本 (#6098)
增加了多端口服务(#6182)
- 新入门指南
- 多节点本地启动指南 (#6505)
- Google 云平台上的 Mesos (#5442)
- Ansible 安装说明 (#6237)
添加了一个控制器框架 (#5270, #5473)
Kubelet 现在监听一个安全的 HTTPS 端口 (#6380)
使 kubectl 错误更加友好 (#6338)
apiserver 现在支持客户端 cert 身份验证 (#6190)
apiserver 现在限制了它处理的并发请求的数量 (#6207)
添加速度限制删除 pod (#6355)
将平衡资源分配算法作为优先级函数实现在调度程序包中 (#6150)
从主服务器启用日志收集功能 (#6396)
添加了一个 api 端口来从 Pod 中提取日志 (#6497)
为调度程序添加了延迟指标 (#6368)
为 REST 客户端添加了延迟指标 (#6409)

etcd 现在在 master 上的一个 pod 中运行 (#6221)
nginx 现在在 master上的容器中运行 (#6334)
开始为主组件构建 Docker 镜像 (#6326)
更新了 GCE 程序以使用 gcloud 0.9.54 (#6270)
更新了 AWS 程序来修复区域与区域语义 (#6011)
记录镜像 GC 失败时的事件 (#6091)
为 kubernetes 客户端添加 QPS 限制器 (#6203)
减少运行 make release 所需的时间 (#6196)
新卷的支持
- 添加 iscsi 卷插件 (#5506)
- 添加 glusterfs 卷插件 (#6174)
- AWS EBS 卷支持 (#5138)
更新到 heapster 版本到 v0.10.0 (#6331)
更新到 etcd 2.0.9 (#6544)
更新到 Kibana 到 v1.2 (#6426)
漏洞修复
- 如果服务的公共 IP 发生变化，Kube-proxy现在会更新iptables规则 (#6123)
- 如果初始创建失败，则重试 kube-addons 创建 (#6200)
- 使 kube-proxy 对耗尽文件描述符更具弹性 (#6727)

要下载，请访问 https://github.com/GoogleCloudPlatform/kubernetes/releases/tag/v0.15.0

每周 Kubernetes 社区例会笔记 - 2015 年 4 月 3 日

Sat, 04 Apr 2015 00:00:00 +0000

Kubernetes: 每周 Kubernetes 社区聚会笔记

每周，Kubernetes 贡献社区几乎都会通过 Google Hangouts 开会。我们希望任何有兴趣的人都知道本论坛讨论的内容。

议程：

Quinton - 集群联邦
Satnam - 性能基准测试更新

会议记录：

Kubernetes 社区每周聚会笔记 - 2015 年 3 月 27 日

Sat, 28 Mar 2015 00:00:00 +0000

每个星期，Kubernetes 贡献者社区几乎都会在谷歌 Hangouts 上聚会。我们希望任何对此感兴趣的人都能了解这个论坛的讨论内容。

日程安排：

- Andy - 演示远程执行和端口转发

Kubernetes 采集视频

Mon, 23 Mar 2015 00:00:00 +0000

如果你错过了上个月在旧金山举行的 Kubernetes 大会，不要害怕!以下是在 YouTube 上组织成播放列表的晚间演示文稿中的视频。

欢迎来到 Kubernetes 博客!

Fri, 20 Mar 2015 00:00:00 +0000

欢迎来到新的 Kubernetes 博客。关注此博客，了解 Kubernetes 开源项目。我们计划时不时的发布发布说明，操作方法文章，活动，甚至一些非常有趣的话题。

如果您正在使用 Kubernetes 或为该项目做出贡献并想要发帖子，请告诉我。

Mon, 01 Jan 0001 00:00:00 +0000

云原生计算基金会（CNCF）社区行为准则 1.3 版本

社区行为准则

作为 CNCF 社区的贡献者、维护者和参与者，我们努力建设一个开放和受欢迎的社区，我们承诺尊重所有上报 Issue、发布功能需求、更新文档、提交 PR 或补丁、参加会议活动以及其他社区和项目活动的贡献者和参与者。

Mon, 01 Jan 0001 00:00:00 +0000

本路径下的文件从其它地方导入。除了版本更新，不要直接修改。本地化说明：你无需为此目录中的任何文件创建本地化版本。

Mon, 01 Jan 0001 00:00:00 +0000

需求

你需要一台 Linux 或 macOS 机器。
你需要安装以下工具：
- Python v3.7.x+
- Git
- Golang 1.13+ 版本
- 用来安装 PyYAML 的 Pip
- PyYAML v5.1.2
- make
- gcc compiler/linker
- Docker （仅用于 kubectl 命令参考）

你的 PATH 环境变量必须包含所需要的构建工具，例如 Go 程序和 python。

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm：轻松创建一个安全的 Kubernetes 集群

概要

┌──────────────────────────────────────────────────────────┐
│ KUBEADM │
│ 轻松创建一个安全的 Kubernetes 集群 │
│ │
│ 给我们反馈意见的地址： │
│ https://github.com/kubernetes/kubeadm/issues │
└──────────────────────────────────────────────────────────┘

用途示例：

创建一个有两台机器的集群，包含一个控制平面节点（用来控制集群）和一个工作节点（运行你的 Pod 和 Deployment 等工作负载）。

Mon, 01 Jan 0001 00:00:00 +0000

生成证书密钥。

概要

该命令将打印出可以与 "init" 命令一起使用的安全的随机生成的证书密钥。

你也可以使用 kubeadm init --upload-certs 而无需指定证书密钥；此命令将为你生成并打印一个证书密钥。

kubeadm certs certificate-key [flags]

选项

-h, --help

certificate-key 操作的帮助命令。

Mon, 01 Jan 0001 00:00:00 +0000

为一个 Kubernetes 集群检查证书的到期时间。

概要

检查 kubeadm 管理的本地 PKI 中证书的到期时间。

kubeadm certs check-expiration [flags]

选项

--allow-missing-template-keys 默认值：true

如果为 true，忽略模板中缺少某字段或映射键的错误。仅适用于 golang 和 jsonpath 输出格式。

Mon, 01 Jan 0001 00:00:00 +0000

生成密钥和证书签名请求。

概要

为运行控制平面所需的所有证书生成密钥和证书签名请求（CSR）。该命令会生成部分 kubeconfig 文件，其中 "users > user > client-key-data" 字段包含私钥数据，并为每个 kubeconfig 文件创建一个随附的 ".csr" 文件。

Mon, 01 Jan 0001 00:00:00 +0000

概要

为 Kubernetes 集群更新证书

kubeadm certs renew [flags]

选项

-h, --help
	renew 操作的帮助命令

从父命令继承的选项

--rootfs string

[实验] 到 '真实' 主机根文件系统的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

续订 kubeconfig 文件中嵌入的证书，供管理员和 kubeadm 自身使用。

无论证书的到期日期如何，续订都是无条件进行的；SAN 等额外属性将基于现有文件/证书，因此无需重新提供它们。

默认情况下，续订会尝试使用由 kubeadm 管理的本地 PKI 中的证书机构；作为替代方案，也可以使用 K8s 证书 API 进行证书续订，或者（作为最后一种选择）生成 CSR 请求。

Mon, 01 Jan 0001 00:00:00 +0000

续订所有可用证书。

概要

续订运行控制平面所需的所有已知证书。续订是无条件进行的，与到期日期无关。续订也可以单独运行以进行更多控制。

kubeadm certs renew all [flags]

选项

--cert-dir string 默认值："/etc/kubernetes/pki"

概要

续订 apiserver 用于访问 etcd 的证书。

无论证书的到期日期如何，续订都会无条件地进行；SAN 等额外属性将基于现有文件/证书，因此无需重新提供它们。

默认情况下，续订尝试使用在 kubeadm 所管理的本地 PKI 中的证书颁发机构；作为替代方案，可以使用 K8s 证书 API 进行证书更新，或者（作为最后一个选项）生成 CSR 请求。

Mon, 01 Jan 0001 00:00:00 +0000

概要

续订 apiserver 用于连接 kubelet 的证书。

无论证书的到期日期如何，续订都会无条件地进行；SAN 等额外属性将基于现有文件/证书，因此无需重新提供它们。

默认情况下，续订尝试使用位于 kubeadm 所管理的本地 PKI 中的证书颁发机构；作为替代方案，也可能调用 K8s 证书 API 进行证书更新；亦或者，作为最后一个选择，生成 CSR 请求。

Mon, 01 Jan 0001 00:00:00 +0000

概要

续订用于提供 Kubernetes API 的证书。

无论证书的到期日期如何，续订都会无条件地进行；SAN 等额外属性将基于现有文件/证书，因此无需重新提供它们。

默认情况下，续订尝试在 kubeadm 管理的本地 PKI 中使用证书颁发机构；作为替代方案，可以使用 K8s 证书 API 进行证书更新，或者作为最后一个选择来生成 CSR 请求。

Mon, 01 Jan 0001 00:00:00 +0000

概要

续订 kubeconfig 文件中嵌入的证书，以供控制器管理器（Controller Manager）使用。

续订无条件地进行，与证书的到期日期无关；SAN 等额外属性将基于现有的文件/证书，因此无需重新提供它们。

默认情况下，续订会尝试使用 kubeadm 管理的本地 PKI 中的证书颁发机构；作为替代方案，可以使用 K8s 证书 API 进行证书续订；亦或者，作为最后一种选择，生成 CSR 请求。

Mon, 01 Jan 0001 00:00:00 +0000

概要

续订存活态探针的证书，用于对 etcd 执行健康检查。

无论证书的到期日期如何，续订都是无条件进行的；SAN 等额外属性将基于现有文件/证书，因此无需重新提供它们。

默认情况下，续订会尝试使用由 kubeadm 管理的本地 PKI 中的证书机构；作为替代方案，也可以使用 K8s certificate API 进行证书续订，或者（作为最后一种选择）生成 CSR 请求。

Mon, 01 Jan 0001 00:00:00 +0000

概要

续订 etcd 节点间用来相互通信的证书。

无论证书的到期日期如何，续订都是无条件进行的；SAN 等额外属性将基于现有文件/证书，因此无需重新提供它们。

Mon, 01 Jan 0001 00:00:00 +0000

概要

续订用于提供 etcd 服务的证书。

续订无条件地进行，与证书的到期日期无关；SAN 等额外属性将基于现有的文件/证书，因此无需重新提供它们。

默认情况下，续订会尝试在 kubeadm 管理的本地 PKI 中使用证书颁发机构；作为替代方案，可以使用 K8s 证书 API 进行证书续订，或者作为最后一种选择来生成 CSR 请求。

Mon, 01 Jan 0001 00:00:00 +0000

概要

为前端代理客户端续订证书。

无论证书的到期日期如何，续订都会无条件地进行；SAN 等额外属性将基于现有文件/证书，因此无需重新提供它们。

默认情况下，续订尝试使用位于 kubeadm 所管理的本地 PKI 中的证书颁发机构；作为替代方案，也可以使用 K8s certificate API 进行证书续订；亦或者，作为最后一种方案，生成 CSR 请求。

Mon, 01 Jan 0001 00:00:00 +0000

概要

续订 kubeconfig 文件中嵌入的证书，以供调度管理器使用。

续订无条件地进行，与证书的到期日期无关；SAN 等额外属性将基于现有的文件/证书，因此无需重新提供它们。

默认情况下，续订会尝试使用在 kubeadm 所管理的本地 PKI 中的证书颁发机构；作为替代方案，也可以使用 K8s certificate API 进行证书续订；亦或者，作为最后一种选择，生成 CSR 请求。

Mon, 01 Jan 0001 00:00:00 +0000

概要

为 super-admin 对嵌入于 kubeconfig 文件中的证书续期。

续期操作将无条件进行，不论证书的到期日期是何时；诸如 SAN 之类的额外属性将基于现有文件/证书，无需重新提供。

Mon, 01 Jan 0001 00:00:00 +0000

概要

与 kubeadm 使用的容器镜像交互。

kubeadm config images [flags]

选项

-h, --help
	images 的帮助命令。

从父命令继承的选项

--kubeconfig string 默认值："/etc/kubernetes/admin.conf"

用于和集群通信的 kubeconfig 文件。如果它没有被设置，那么 kubeadm 将会搜索一个已经存在于标准路径的 kubeconfig 文件。

Mon, 01 Jan 0001 00:00:00 +0000

概要

打印 kubeadm 要使用的镜像列表。配置文件用于自定义镜像或镜像存储库。

kubeadm config images list [flags]

选项

--allow-missing-template-keys 默认值：true

如果设置为 true，则在模板中缺少字段或哈希表的键时忽略模板中的任何错误。仅适用于 golang 和 jsonpath 输出格式。

Mon, 01 Jan 0001 00:00:00 +0000

概要

拉取 kubeadm 使用的镜像。

kubeadm config images pull [flags]

选项

--config string

kubeadm 配置文件的路径。

--cri-socket string

要连接的 CRI 套接字的路径。如果为空，则 kubeadm 将尝试自动检测此值；仅当安装了多个 CRI 或具有非标准 CRI 插槽时，才使用此选项。

Mon, 01 Jan 0001 00:00:00 +0000

从文件中读取旧版本的 kubeadm 配置的 API 类型，并为新版本输出类似的配置对象

概要

此命令允许你在 CLI 工具中将本地旧版本的配置对象转换为最新支持的版本，而无需变更集群中的任何内容。在此版本的 kubeadm 中，支持以下 API 版本：

Mon, 01 Jan 0001 00:00:00 +0000

打印配置

概要

此命令打印子命令所提供的配置信息。相关细节可参阅： https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories

kubeadm config print [flags]

选项

-h, --help
	print 命令的帮助信息。

从父命令继承而来的选项

--kubeconfig string 默认值："/etc/kubernetes/admin.conf"

打印用于 'kubeadm init' 的默认 init 配置。

概要

此命令打印对象，例如用于 'kubeadm init' 的默认 init 配置对象。

请注意，Bootstrap Token 字段之类的敏感值已替换为 "abcdef.0123456789abcdef" 之类的占位符值以通过验证，但不执行创建令牌的实际计算。

Mon, 01 Jan 0001 00:00:00 +0000

打印默认的节点添加配置，该配置可用于 'kubeadm join' 命令。

概要

此命令打印对象，例如用于 'kubeadm join' 的默认 join 配置对象。

请注意，诸如启动引导令牌字段之类的敏感值已替换为 "abcdef.0123456789abcdef" 之类的占位符值以通过验证，但不执行创建令牌的实际计算。

Mon, 01 Jan 0001 00:00:00 +0000

打印默认的 reset 配置，该配置可用于 'kubeadm reset' 命令。

概要

此命令打印 'kubeadm reset' 所用的默认 reset 配置等这类对象。

请注意，诸如启动引导令牌（Bootstrap Token）字段这类敏感值已替换为 "abcdef.0123456789abcdef" 这类占位符值用来通过合法性检查，但不执行创建令牌的实际计算。

Mon, 01 Jan 0001 00:00:00 +0000

打印可用于 kubeadm upgrade 的默认升级配置。

概要

此命令打印 kubeadm upgrade 所用的默认升级配置等这类对象。

Mon, 01 Jan 0001 00:00:00 +0000

读取包含 kubeadm 配置 API 的文件，并报告所有验证问题。

概要

这个命令允许你验证 kubeadm 配置 API 文件并报告所有警告和错误。如果没有错误，退出状态将为零；否则，将为非零。诸如未知 API 字段等任何解包问题都会触发错误。未知的 API 版本和具有无效值的字段也会触发错误。根据输入文件的内容，可能会报告任何其他错误或警告。

Mon, 01 Jan 0001 00:00:00 +0000

概要

使用此命令可以调用 "init" 工作流程的单个阶段：

kubeadm init phase [flags]

选项

-h, --help
	phase 操作的帮助命令。

继承于父命令的选择项

--rootfs string

[实验] 到 '真实' 主机根文件系统的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

安装必要的插件以通过一致性测试。

kubeadm init phase addon [flags]

选项

-h, --help
	addon 操作的帮助命令。

继承于父命令的选项

--rootfs string

[实验] 到 '真实' 主机根文件系统的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

安装所有插件（addon）。

kubeadm init phase addon all [flags]

选项

--apiserver-advertise-address string

API 服务器所公布的其正在监听的 IP 地址。如果未设置，则将使用默认网络接口。

--apiserver-bind-port int32 默认值：6443

API 服务器绑定的端口。

Mon, 01 Jan 0001 00:00:00 +0000

概要

通过 API 服务器安装 CoreDNS 附加组件。请注意，即使 DNS 服务器已部署，在安装 CNI 之前 DNS 服务器不会被调度执行。

kubeadm init phase addon coredns [flags]

选项

--config string

kubeadm 配置文件的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

通过 API 服务器安装 kube-proxy 附加组件。

kubeadm init phase addon kube-proxy [flags]

选项

--apiserver-advertise-address string

API 服务器所公布的其正在监听的 IP 地址。如果未设置，则将使用默认网络接口。

--apiserver-bind-port int32 默认值: 6443

生成用于将节点加入集群的引导令牌

概要

启动引导令牌（bootstrap token）用于在即将加入集群的节点和控制平面节点之间建立双向信任。

该命令使启动引导令牌（bootstrap token）所需的所有配置生效，然后创建初始令牌。

kubeadm init phase bootstrap-token [flags]

示例

# 进行所有引导令牌配置，并创建一个初始令牌，功能上与 kubeadm init 生成的令牌等效。
kubeadm init phase bootstrap-token

选项

--config string

概要

证书生成：

kubeadm init phase certs [flags]

选项

-h, --help
	certs 操作的帮助命令。

从父指令中继承的选项

--rootfs string

[实验] 到'真实'主机根文件系统的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成所有证书。

kubeadm init phase certs all [flags]

选项

--apiserver-advertise-address string

API 服务器所公布的其正在监听的 IP 地址。如果未设置，将使用默认网络接口。

--apiserver-cert-extra-sans strings

用于 API 服务器服务证书的可选额外替代名称（SAN）。可以同时使用 IP 地址和 DNS 名称。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成 apiserver 用于访问 etcd 的证书，并将其保存到 apiserver-etcd-client.crt 和 apiserver-etcd-client.key 文件中。

如果两个文件都已存在，则 kubeadm 将跳过生成步骤，使用现有文件。

kubeadm init phase certs apiserver-etcd-client [flags]

选项

--cert-dir string 默认值："/etc/kubernetes/pki"

证书的存储路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成供 API 服务器连接 kubelet 的证书，并将其保存到 apiserver-kubelet-client.crt 和 apiserver-kubelet-client.key 文件中。

如果两个文件都已存在，则 kubeadm 将跳过生成步骤，使用现有文件。

kubeadm init phase certs apiserver-kubelet-client [flags]

选项

--cert-dir string 默认值："/etc/kubernetes/pki"

存储证书的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成用于服务 Kubernetes API 的证书，并将其保存到 apiserver.crt 和 apiserver.key 文件中。

如果两个文件都已存在，则 kubeadm 将跳过生成步骤，使用现有文件。

kubeadm init phase certs apiserver [flags]

选项

--apiserver-advertise-address string

API 服务器所公布的其正在监听的 IP 地址。如果未设置，则使用默认的网络接口。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成自签名的 Kubernetes CA 以便为其他 Kubernetes 组件提供身份标识，并将其保存到 ca.crt 和 ca.key 文件中。

如果两个文件都已存在，则 kubeadm 将跳过生成步骤，使用现有文件。

kubeadm init phase certs ca [flags]

选项

--cert-dir string 默认值："/etc/kubernetes/pki"

证书的存储路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成用于为 etcd 设置身份的自签名 CA，并将其保存到 etcd/ca.crt 和 etcd/ca.key 文件中。

如果两个文件都已存在，则 kubeadm 将跳过生成步骤，使用现有文件。

kubeadm init phase certs etcd-ca [flags]

选项

--cert-dir string 默认值："/etc/kubernetes/pki"

证书的存储路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成用于 etcd 健康检查的活跃性探针的证书，并将其保存到 etcd/healthcheck-client.crt 和 etcd/healthcheck-client.key 文件中。

如果两个文件都已存在，则 kubeadm 将跳过生成步骤，使用现有文件。

kubeadm init phase certs etcd-healthcheck-client [flags]

选项

--cert-dir string 默认值："/etc/kubernetes/pki"

证书存储的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成 etcd 节点相互通信的证书，并将其保存到 etcd/peer.crt 和 etcd/peer.key 文件中。

默认 SAN 为 localhost、127.0.0.1、127.0.0.1、::1

如果两个文件都已存在，则 kubeadm 将跳过生成步骤，使用现有文件。

kubeadm init phase certs etcd-peer [flags]

选项

--cert-dir string 默认值："/etc/kubernetes/pki"

保存和存储证书的路径。

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis

-->

概要

生成用于提供 etcd 服务的证书，并将其保存到 etcd/server.crt 和 etcd/server.key 文件中。

默认 SAN 为 localhost、127.0.0.1、127.0.0.1、::1

如果两个文件都已存在，则 kubeadm 将跳过生成步骤，使用现有文件。

kubeadm init phase certs etcd-server [flags]

选项

--cert-dir string 默认值："/etc/kubernetes/pki"
	保存和存储证书的路径。
--config string
	kubeadm 配置文件的路径。
--dry-run
	不做任何更改；只输出将要执行的操作。
-h, --help
	etcd-server 操作的帮助命令。
--kubernetes-version string 默认值："stable-1"
	为控制平面指定特定的 Kubernetes 版本。

继承于父命令的选项

--rootfs string

[实验] 到 '真实' 主机根文件系统的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成自签名 CA 来提供前端代理的身份，并将其保存到 front-proxy-ca.cert 和 front-proxy-ca.key 文件中。

如果两个文件都已存在，kubeadm 将跳过生成步骤并将使用现有文件。

kubeadm init phase certs front-proxy-ca [flags]

选项

--cert-dir string 默认值："/etc/kubernetes/pki"

存储证书的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

为前端代理客户端生成证书，并将其保存到 front-proxy-client.crt 和 front-proxy-client.key 文件中。

如果两个文件都已存在，kubeadm 将跳过生成步骤并将使用现有文件。

kubeadm init phase certs front-proxy-client [flags]

选项

--cert-dir string 默认："/etc/kubernetes/pki"

存储证书的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成用来签署服务账号令牌的私钥及其公钥，并将其保存到 sa.key 和 sa.pub 文件中。

如果两个文件都已存在，则 kubeadm 会跳过生成步骤，而将使用现有文件。

kubeadm init phase certs sa [flags]

选项

--cert-dir string 默认值："/etc/kubernetes/pki"

保存和存储证书的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成建立控制平面所需的所有静态 Pod 的清单文件

kubeadm init phase control-plane [flags]

选项

-h, --help
	control-plane 操作的帮助命令。

继承于父命令的选项

--rootfs string

[实验] 到'真实'主机根文件系统的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成所有的静态 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 地址。如果未设置，将使用默认的网络接口。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成 kube-apiserver 静态 Pod 清单。

kubeadm init phase control-plane apiserver [flags]

选项

--apiserver-advertise-address string

API 服务器所公布的其正在监听的 IP 地址。如果未设置，将使用默认网络接口。

--apiserver-bind-port int32 默认值：6443

要绑定到 API 服务器的端口。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成 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 <comma-separated 'key=value' pairs>

一组 <flagname>=< 形式的额外参数，传递给控制器管理器（Controller Manager）或者覆盖其默认配置值

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成 kube-scheduler 静态 Pod 清单。

kubeadm init phase control-plane scheduler [flags]

选项

--cert-dir string 默认值："/etc/kubernetes/pki"

存储证书的路径。

--config string

kubeadm 配置文件的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

为本地 etcd 创建静态 Pod 清单。

kubeadm init phase etcd [flags]

选项

-h, --help
	etcd 操作的帮助命令。

继承于父命令的选项

--rootfs string

[实验] 到 '真实' 主机根文件系统的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

为本地单节点 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"

存储证书的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成建立控制平面和管理 kubeconfig 文件所需的所有 kubeconfig 文件。

kubeadm init phase kubeconfig [flags]

选项

-h, --help
	kubeconfig 操作的帮助命令

从父命令继承的选项

--rootfs string

[实验] 到'真实'主机根文件系统的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

为管理员和 kubeadm 本身生成 kubeconfig 文件，并将其保存到 admin.conf 文件中。

kubeadm init phase kubeconfig admin [flags]

选项

--apiserver-advertise-address string

API 服务器所公布的其正在监听的 IP 地址。如果未设置，则使用默认的网络接口。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成所有 kubeconfig 文件。

kubeadm init phase kubeconfig all [flags]

选项

--apiserver-advertise-address string

API 服务器所公布的其正在监听的 IP 地址。如果没有设置，将使用默认的网络接口。

--apiserver-bind-port int32 默认值：6443

要绑定到 API 服务器的端口。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成控制器管理器要使用的 kubeconfig 文件，并保存到 controller-manager.conf 文件中。

kubeadm init phase kubeconfig controller-manager [flags]

选项

--apiserver-advertise-address string

API 服务器所公布的其正在监听的 IP 地址。如果未设置，则使用默认的网络接口。

Mon, 01 Jan 0001 00:00:00 +0000

为 kubelet 生成一个 kubeconfig 文件，仅仅用于集群引导目的。

概要

生成 kubelet 要使用的 kubeconfig 文件，并将其保存到 kubelet.conf 文件。

请注意，该操作目的是仅用于引导集群。在控制平面启动之后，应该从 CSR API 请求所有 kubelet 凭据。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成调度器（scheduler）要使用的 kubeconfig 文件，并保存到 scheduler.conf 文件中。

kubeadm init phase kubeconfig scheduler [flags]

选项

--apiserver-advertise-address string

API 服务器所公布的其正在监听的 IP 地址。如果未设置，则使用默认的网络接口。

Mon, 01 Jan 0001 00:00:00 +0000

概要

为 super-admin 生成一个 kubeconfig 文件，并将其保存到 super-admin.conf 文件中。

kubeadm init phase kubeconfig super-admin [flags]

选项

--apiserver-advertise-address string

API 服务器所公布其监听的 IP 地址。如果未设置，则使用默认的网络接口。

Mon, 01 Jan 0001 00:00:00 +0000

概要

TLS 引导后更新与 kubelet 相关的设置。

kubeadm init phase kubelet-finalize [flags]

示例

# 在 TLS 引导后更新与 kubelet 相关的设置
kubeadm init phase kubelet-finalize all --config

选项

-h, --help

kubelet-finalize 操作的帮助命令。

Mon, 01 Jan 0001 00:00:00 +0000

概要

运行 kubelet-finalize 的所有阶段

kubeadm init phase kubelet-finalize all [flags]

示例

# 在 TLS 引导后更新与 kubelet 相关的设置
kubeadm init phase kubelet-finalize all --config

选项

--cert-dir string 默认值: "/etc/kubernetes/pki"

保存和存储证书的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

启用 kubelet 客户端证书轮换

kubeadm init phase kubelet-finalize enable-client-cert-rotation [flags]

选项

--cert-dir string 默认值："/etc/kubernetes/pki"

保存和存储证书的路径。

--config string

kubeadm 配置文件的路径。

--dry-run

不做任何更改；只输出将要执行的操作。

Mon, 01 Jan 0001 00:00:00 +0000

概要

使用 kubelet 配置文件编写一个文件，并使用特定节点的 kubelet 设置编写一个环境文件，然后（重新）启动 kubelet。

kubeadm init phase kubelet-start [flags]

示例

# 将来自 InitConfiguration 文件中的 kubelet 参数写入一个动态环境文件。
kubeadm init phase kubelet-start --config config.yaml

选项

--config string

kubeadm 配置文件的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

标记节点为控制平面节点。

kubeadm init phase mark-control-plane [flags]

示例

# 将控制平面标签和污点应用于当前节点，其功能等效于 kubeadm init 执行的操作
kubeadm init phase mark-control-plane --config config.yaml

# 将控制平面标签和污点应用于特定节点
kubeadm init phase mark-control-plane --node-name myNode

选项

--config string

kubeadm 配置文件的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

运行 kubeadm init 前的预检。

kubeadm init phase preflight [flags]

示例

# 使用配置文件对 kubeadm init 进行预检
kubeadm init phase preflight --config kubeadm-config.yaml

选项

--config string

kubeadm 配置文件的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

显示针对控制平面和工作节点的 join 命令。

kubeadm init phase show-join-command [flags]

选项

-h, --help
	show-join-command 操作的帮助命令。

从父命令继承的选项

--rootfs string

[实验] 到 '真实' 主机根文件系统的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

将控制平面证书上传到 kubeadm-certs Secret。

kubeadm init phase upload-certs [flags]

选项

--certificate-key string

用于加密 kubeadm-certs Secret 中的控制平面证书的密钥。证书密钥是十六进制编码的字符串，是大小为 32 字节的 AES 密钥。

Mon, 01 Jan 0001 00:00:00 +0000

概要

上传 kubeadm 和 kubelet 配置到 ConfigMap 中。

kubeadm init phase upload-config [flags]

选项

-h, --help
	upload-config 操作的帮助命令。

从父命令中继承的选项

--rootfs string

[实验] 到 '真实' 主机根文件系统的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

将所有配置上传到 ConfigMap

kubeadm init phase upload-config all [flags]

选项

--config string

kubeadm 配置文件的路径。

--cri-socket string

要连接的 CRI 套接字的路径。如果该值为空，kubeadm 将尝试自动检测；仅当你安装了多个 CRI 或使用非标准的 CRI 套接字时才应使用此选项。

Mon, 01 Jan 0001 00:00:00 +0000

概要

将 kubeadm ClusterConfiguration 上传到 kube-system 命名空间中名为 kubeadm-config 的 ConfigMap 中。这样就可以正确配置系统组件，并在升级时提供无缝的用户体验。

另外，可以使用 kubeadm 配置。

kubeadm init phase upload-config kubeadm [flags]

示例

# 上传集群配置
kubeadm init phase upload-config kubeadm --config=myConfig.yaml

选项

--config string

kubeadm 配置文件的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

将从 kubeadm InitConfiguration 对象提取的 kubelet 配置上传到集群中的 kubelet-config ConfigMap。

kubeadm init phase upload-config kubelet [flags]

示例

# 将 kubelet 配置从 kubeadm 配置文件上传到集群中的 ConfigMap。
kubeadm init phase upload-config kubelet --config kubeadm.yaml

选项

--config string

到 kubeadm 配置文件的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

等待控制平面启动。

kubeadm init phase wait-control-plane [flags]

选项

-h, --help
	wait-control-plane 操作的帮助命令。

从父命令继承的选项

--rootfs string

到“真实”主机根文件系统的路径。设置此参数将导致 kubeadm 切换到所提供的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

使用此命令来调用 join 工作流程的某个阶段。

kubeadm join phase [flags]

选项

-h, --help
	phase 操作的帮助命令。

从父命令中继承的选项

--rootfs string

[实验] 指向 '真实' 宿主机根文件系统的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

添加作为控制平面实例的机器。

kubeadm join phase control-plane-join [flags]

示例

# 将机器作为控制平面实例加入
kubeadm join phase control-plane-join all

选项

-h, --help

control-plane-join 操作的帮助命令。

Mon, 01 Jan 0001 00:00:00 +0000

概要

添加作为控制平面实例的机器。

kubeadm join phase control-plane-join all [flags]

选项

--apiserver-advertise-address string

如果该节点托管一个新的控制平面实例，则 API 服务器将公布其正在侦听的 IP 地址。如果未设置，则使用默认网络接口。

Mon, 01 Jan 0001 00:00:00 +0000

概要

添加新的本地 etcd 成员。

kubeadm join phase control-plane-join etcd [flags]

选项

--apiserver-advertise-address string

如果该节点托管一个新的控制平面实例，则 API 服务器将公布其正在侦听的 IP 地址。如果未设置，则使用默认网络接口。

Mon, 01 Jan 0001 00:00:00 +0000

概要

将节点标记为控制平面节点。

kubeadm join phase control-plane-join mark-control-plane [flags]

选项

--config string

kubeadm 配置文件的路径。

--control-plane

在此节点上创建一个新的控制平面实例。

--dry-run

不做任何更改；只输出将要执行的操作。

Mon, 01 Jan 0001 00:00:00 +0000

概要

准备为控制平面服务的机器。

kubeadm join phase control-plane-prepare [flags]

示例

# 准备为控制平面服务的机器
kubeadm join phase control-plane-prepare all

选项

-h, --help

control-plane-prepare 操作的帮助命令。

Mon, 01 Jan 0001 00:00:00 +0000

概要

准备为控制平面服务的机器。

kubeadm join phase control-plane-prepare all [api-server-endpoint] [flags]

选项

--apiserver-advertise-address string

如果该节点托管一个新的控制平面实例，则 API 服务器将公布其正在侦听的 IP 地址。如果未设置，则使用默认网络接口。

Mon, 01 Jan 0001 00:00:00 +0000

概要

为新的控制平面组件生成证书。

kubeadm join phase control-plane-prepare certs [api-server-endpoint] [flags]

选项

--apiserver-advertise-address string

如果该节点托管一个新的控制平面实例，则 API 服务器将公布其正在侦听的 IP 地址。如果未设置，则使用默认网络接口。

Mon, 01 Jan 0001 00:00:00 +0000

概要

为新的控制平面组件生成清单（manifest）。

kubeadm join phase control-plane-prepare control-plane [flags]

选项

--apiserver-advertise-address string

对于将要托管新的控制平面实例的节点，指定 API 服务器将公布的其正在侦听的 IP 地址。如果未设置，则使用默认网络接口。

Mon, 01 Jan 0001 00:00:00 +0000

概要

从 kubeadm-certs Secret 下载控制平面节点之间共享的证书。

kubeadm join phase control-plane-prepare download-certs [api-server-endpoint] [flags]

选项

--certificate-key string

使用此密钥可以解密由 init 上传的证书 Secret。证书密钥为一个十六进制编码的字符串，是大小为 32 字节的 AES 密钥。

Mon, 01 Jan 0001 00:00:00 +0000

概要

为新的控制平面组件生成 kubeconfig。

kubeadm join phase control-plane-prepare kubeconfig [api-server-endpoint] [flags]

选项

--certificate-key string

使用此密钥可以解密由 init 上传的证书 Secret。证书密钥为一个十六进制编码的字符串，它是大小为 32 字节的 AES 密钥。

Mon, 01 Jan 0001 00:00:00 +0000

概要

生成一个包含 KubeletConfiguration 的文件和一个包含特定于节点的 kubelet 配置的环境文件，然后（重新）启动 kubelet。

kubeadm join phase kubelet-start [api-server-endpoint] [flags]

选项

--config string

kubeadm 配置文件的路径。

--cri-socket string

提供给 CRI 套接字建立连接的路径。如果为空，则 kubeadm 将尝试自动检测该值；仅当安装了多个 CRI 或存在非标准的 CRI 套接字时，才使用此选项。

Mon, 01 Jan 0001 00:00:00 +0000

概要

等待 kubelet 完成自身的引导初始化。

kubeadm join phase kubelet-wait-bootstrap [flags]

选项

--config string

kubeadm 配置文件的路径。

--cri-socket string

要连接的 CRI 套接字的路径。如果为空，kubeadm 将尝试自动检测此值；仅当安装了多个 CRI 或具有非标准 CRI 套接字时，才使用此选项。

Mon, 01 Jan 0001 00:00:00 +0000

概要

运行 kubeadm join 命令添加节点前检查。

kubeadm join phase preflight [api-server-endpoint] [flags]

示例

# 使用配置文件运行 kubeadm join 命令添加节点前检查。
kubeadm join phase preflight --config kubeadm-config.yaml

选项

--apiserver-advertise-address string

对于将要托管新的控制平面实例的节点，指定 API 服务器将公布的其正在侦听的 IP 地址。如果未设置，则使用默认网络接口。

Mon, 01 Jan 0001 00:00:00 +0000

概要

等待控制平面启动

kubeadm join phase wait-control-plane [flags]

选项

-h, --help
	wait-control-plane 操作的帮助命令。

从父命令继承的选项

--rootfs string

[实验] 到 '真实' 主机根文件系统的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

为其他用户输出一个 kubeconfig 文件。

kubeadm kubeconfig user [flags]

示例

# 为一个名为 foo 的其他用户输出 kubeconfig 文件
kubeadm kubeconfig user --client-name=foo

# 使用 kubeadm 配置文件 bar 为另一个名为 foo 的用户输出 kubeconfig 文件
kubeadm alpha kubeconfig user --client-name=foo --config=bar

选项

--client-name string

用户名。如果生成客户端证书，则用作其 CN。

Mon, 01 Jan 0001 00:00:00 +0000

概要

使用此命令来调用 reset 工作流程的某个阶段：

kubeadm reset phase [flags]

选项

-h, --help
	phase 操作的帮助命令。

从父命令继承的选项

--rootfs string

到“真实”主机根文件系统的路径。这将导致 kubeadm 切换到所提供的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

执行 cleanup node（清理节点）操作。

kubeadm reset phase cleanup-node [flags]

选项

--cert-dir string 默认值："/etc/kubernetes/pki"

存储证书的目录路径。如果已指定，则需要清空此目录。

--cleanup-tmp-dir

清理 "/etc/kubernetes/tmp" 目录。

--cri-socket string

要连接的 CRI 套接字的路径。如果为空，则 kubeadm 将尝试自动检测此值；仅当安装了多个 CRI 或具有非标准 CRI 套接字时，才使用此选项。

Mon, 01 Jan 0001 00:00:00 +0000

概要

kubeadm reset（重置）前运行启动前检查。

kubeadm reset phase preflight [flags]

选项

--dry-run

不做任何更改；只输出将要执行的操作。

-f, --force

在不提示确认的情况下重置节点。

-h, --help

preflight 操作的帮助命令。

Mon, 01 Jan 0001 00:00:00 +0000

概要

移除控制平面节点的本地 etcd 成员。

kubeadm reset phase remove-etcd-member [flags]

选项

--dry-run

不做任何更改；只输出将要执行的操作。

-h, --help

remove-etcd-member 操作的帮助命令。

--kubeconfig string 默认值："/etc/kubernetes/admin.conf"

与集群通信时使用的 kubeconfig 文件。如果未设置该标志，则可以在默认位置中查找现有的 kubeconfig 文件。

Mon, 01 Jan 0001 00:00:00 +0000

在服务器上创建引导令牌。

概要

这个命令将为你创建一个引导令牌。你可以设置此令牌的用途，"有效时间" 和可选的人性化的描述。

Mon, 01 Jan 0001 00:00:00 +0000

删除服务器上的引导令牌。

概要

这个命令将为你删除指定的引导令牌列表。

[token-value] 是要删除的 "[a-z0-9]{6}.[a-z0-9]{16}" 形式的完整令牌或者是 "[a-z0-9]{6}" 形式的令牌 ID。

kubeadm token delete [token-value] ...

选项

-h, --help

delete 操作的帮助命令。

Mon, 01 Jan 0001 00:00:00 +0000

生成并打印一个引导令牌，但不要在服务器上创建它。

概要

此命令将打印一个随机生成的可以被 "init" 和 "join" 命令使用的引导令牌。

Mon, 01 Jan 0001 00:00:00 +0000

列出服务器上的引导令牌。

概要

此命令将为你列出所有的引导令牌。

kubeadm token list [flags]

选项

--allow-missing-template-keys 默认值：true

如果设置为 true，则在模板中缺少字段或哈希表的键时忽略模板中的任何错误。仅适用于 golang 和 jsonpath 输出格式。

Mon, 01 Jan 0001 00:00:00 +0000

概要

将 Kubernetes 集群升级到指定版本。

kubeadm upgrade apply [version]

apply [version] 命令执行以下阶段：

Mon, 01 Jan 0001 00:00:00 +0000

概要

使用此命令来调用 "apply" 工作流的单个阶段。

kubeadm upgrade apply phase [flags]

选项

-h, --help
	phase 操作的帮助命令。

从父命令继承的选项

--rootfs string

到“真实”主机根文件系统的路径。配置此参数将导致 kubeadm 切换到所提供的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

升级默认的 kubeadm 插件

kubeadm upgrade apply phase addon [flags]

选项

-h, --help
	addon 操作的帮助命令。

从父命令继承的选项

--rootfs string

到“真实”主机根文件系统的路径。设置此参数将导致 kubeadm 切换到所提供的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

升级所有插件。

kubeadm upgrade apply phase addon all [flags]

Options

--config string

kubeadm 配置文件的路径。

--dry-run

不更改任何状态，只输出要执行的操作。

-h, --help

all 操作的帮助命令。

Mon, 01 Jan 0001 00:00:00 +0000

概要

升级 CoreDNS 插件。

kubeadm upgrade apply phase addon coredns [flags]

选项

--config string

kubeadm 配置文件的路径。

--dry-run

不更改任何状态，只输出要执行的操作。

-h, --help

coredns 操作的帮助命令。

Mon, 01 Jan 0001 00:00:00 +0000

概要

升级 kube-proxy 插件。

kubeadm upgrade apply phase addon kube-proxy [flags]

选项

--config string

kubeadm 配置文件的路径。

--dry-run

不改变任何状态，只输出将要执行的操作。

-h, --help

all 操作的帮助命令。

Mon, 01 Jan 0001 00:00:00 +0000

概要

配置启动引导令牌和 cluster-info 的 RBAC 规则

kubeadm upgrade apply phase bootstrap-token [flags]

Options

--config string

kubeadm 配置文件的路径。

--dry-run

不更改任何状态，只输出要执行的操作。

-h, --help

bootstrap-token 操作的帮助命令。

Mon, 01 Jan 0001 00:00:00 +0000

概要

升级控制平面。

kubeadm upgrade apply phase control-plane [flags]

选项

--certificate-renewal 默认值：true

执行升级期间更改的组件所使用的证书的更新。

--config string

kubeadm 配置文件的路径。

--dry-run

不更改任何状态，只输出要执行的操作。

Mon, 01 Jan 0001 00:00:00 +0000

概要

从集群中的 kubelet-config ConfigMap 下载以升级该节点的 kubelet 配置。

kubeadm upgrade apply phase kubelet-config [flags]

选项

--config string

kubeadm 配置文件的路径。

--dry-run

不改变任何状态，只输出将要执行的操作。

Mon, 01 Jan 0001 00:00:00 +0000

概要

运行升级后的任务

kubeadm upgrade apply phase post-upgrade [flags]

选项

--config string

kubeadm 配置文件的路径。

--dry-run

不改变任何状态，只输出将要执行的操作。

-h, --help

post-upgrade 操作的帮助命令。

Mon, 01 Jan 0001 00:00:00 +0000

概要

执行升级前的预检。

kubeadm upgrade apply phase preflight [flags]

选项

--allow-experimental-upgrades

显示 Kubernetes 的不稳定版本作为升级替代方案，并允许升级到 Kubernetes 的 Alpha、Beta 或 RC 版本。

--allow-release-candidate-upgrades

显示 Kubernetes 的发行候选版本作为升级选择，并允许升级到 Kubernetes 的 RC 版本。

Mon, 01 Jan 0001 00:00:00 +0000

概要

将 kubeadm 和 kubelet 配置上传到 ConfigMap。

kubeadm upgrade apply phase upload-config [flags]

选项

-h, --help
	upload-config 操作的帮助命令。

从父命令继承的选项

--rootfs string

“真实”主机根文件系统的路径。设置此参数将导致 kubeadm 切换到所提供的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

将所有配置上传到 ConfigMap。

kubeadm upgrade apply phase upload-config all [flags]

选项

--config string

kubeadm 配置文件的路径。

--dry-run

不改变任何状态，只输出将要执行的操作。

-h, --help

all 操作的帮助命令。

Mon, 01 Jan 0001 00:00:00 +0000

概要

将 kubeadm ClusterConfiguration 上传到 ConfigMap。

kubeadm upgrade apply phase upload-config kubeadm [flags]

选项

--config string

kubeadm 配置文件的路径。

--dry-run

不改变任何状态，只输出将要执行的操作。

Mon, 01 Jan 0001 00:00:00 +0000

概要

将 kubelet 配置上传到 ConfigMap。

kubeadm upgrade apply phase upload-config kubelet [flags]

选项

--config string

kubeadm 配置文件的路径。

--dry-run

不改变任何状态，只输出将要执行的操作。

Mon, 01 Jan 0001 00:00:00 +0000

概要

显示哪些差异将被应用于现有的静态 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 配置文件的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

升级集群中某个节点的命令。

"node" 命令执行以下阶段：

preflight 执行节点升级前检查
control-plane 如果存在的话，升级部署在该节点上的管理面实例
kubelet-config 更新该节点上的 kubelet 配置
addon 升级默认的 kubeadm 插件
 /coredns 升级 CoreDNS 插件
 /kube-proxy 升级 kube-proxy 插件
post-upgrade 运行升级后的任务

kubeadm upgrade node [flags]

选项

--certificate-renewal 默认值：true

对升级期间变化的组件所使用的证书执行续订。

Mon, 01 Jan 0001 00:00:00 +0000

概要

使用此命令调用 node 工作流的某个阶段。

kubeadm upgrade node phase [flags]

选项

-h, --help
	phase 操作的帮助命令。

从父命令继承的选项

--rootfs string

[实验] 指向 '真实' 宿主机根文件系统的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

升级默认的 kubeadm 插件。

kubeadm upgrade node phase addon [flags]

选项

-h, --help
	addon 操作的帮助命令。

从父命令继承的选项

--rootfs string

到“真实”主机根文件系统的路径。设置此参数将导致 kubeadm 切换到所提供的路径。

Mon, 01 Jan 0001 00:00:00 +0000

概要

升级所有插件

kubeadm upgrade node phase addon all [flags]

选项

--config string

kubeadm 配置文件的路径。

--dry-run

不改变任何状态，只输出将要执行的操作。

-h, --help

all 操作的帮助命令。

Mon, 01 Jan 0001 00:00:00 +0000

概要

升级 CoreDNS 插件。

kubeadm upgrade node phase addon coredns [flags]

选项

--config string

kubeadm 配置文件的路径。

--dry-run

不改变任何状态，只输出将要执行的操作。

-h, --help

coredns 操作的帮助命令。

Mon, 01 Jan 0001 00:00:00 +0000

概要

升级 kube-proxy 插件。

kubeadm upgrade node phase addon kube-proxy [flags]

选项

--config string

kubeadm 配置文件的路径。

--dry-run

不改变任何状态，只输出将要执行的操作。

-h, --help

kube-proxy 操作的帮助命令。

Mon, 01 Jan 0001 00:00:00 +0000

概要

升级部署在此节点上的控制平面实例，如果有的话。

kubeadm upgrade node phase control-plane [flags]

选项

--certificate-renewal

续订在升级期间变更的组件所使用的证书。

--config string

kubeadm 配置文件的路径。

--dry-run

不改变任何状态，只输出将要执行的动作。

Mon, 01 Jan 0001 00:00:00 +0000

概要

从集群中的 kubelet-config ConfigMap 下载以升级该节点的 kubelet 配置

kubeadm upgrade node phase kubelet-config [flags]

选项

--config string

kubeadm 配置文件的路径。

--dry-run

不改变任何状态，只输出将要执行的操作。

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis

运行升级后的任务

kubeadm upgrade node phase post-upgrade [flags]

Options

--config string

配置文件的路径。

--dry-run

不改变任何状态，只输出将要执行的操作。

-h, --help

post-upgrade 操作的帮助命令。

--kubeconfig string 默认值："/etc/kubernetes/admin.conf"

用于和集群通信的 kubeconfig 文件。如果它没有被设置，那么 kubeadm 将会搜索一个已经存在于标准路径的 kubeconfig 文件。

Mon, 01 Jan 0001 00:00:00 +0000

执行升级节点的预检。

概要

执行 kubeadm 升级节点的预检。

kubeadm upgrade node phase preflight [flags]

选项

--config string

kubeadm 配置文件的路径。

-h, --help

preflight 操作的帮助命令。

--ignore-preflight-errors strings

错误将显示为警告的检查清单。示例：'IsPrivilegedUser,Swap'。值为 'all' 表示忽略所有检查的错误。

Mon, 01 Jan 0001 00:00:00 +0000

概述

检查可升级到哪些版本，并验证你当前的集群是否可升级。该命令只能在存在 kubeconfig 文件 admin.conf 的控制平面节点上运行。要跳过互联网检查，请传入可选参数 [version]。

kubeadm upgrade plan [version] [flags]

选项

--allow-experimental-upgrades

显示不稳定版本的 Kubernetes 作为升级替代方案，并允许升级到 Kubernetes 的 Alpha、Beta 或 RC 版本。

Mon, 01 Jan 0001 00:00:00 +0000

此目录下的所有文件都是从其他仓库自动生成的。 不要人工编辑它们。你必须在上游仓库中编辑它们

Mon, 01 Jan 0001 00:00:00 +0000

要运行本地化测试，请使用以下命令:

go test k8s.io/website/content/<lang>/examples

其中 <lang> 是用两个字符表示一种语言。例如:

go test k8s.io/website/content/en/examples

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes 文档

本仓库包含了所有用于构建 Kubernetes 网站和文档的软件资产。我们非常高兴你想要参与贡献！

为文档做贡献
README 本地化

使用这个仓库

可以使用 Hugo（扩展版）在本地运行网站，也可以在容器中运行它。强烈建议使用容器，因为这样可以和在线网站的部署保持一致。

Amadeus Case Study

Mon, 01 Jan 0001 00:00:00 +0000

CASE STUDY:

Another Technical Evolution for a 30-Year-Old Company

Company Amadeus IT Group Location Madrid, Spain Industry Travel Technology

Challenge

In the past few years, Amadeus, which provides IT solutions to the travel industry around the world, found itself in need of a new platform for the 5,000 services supported by its service-oriented architecture. The 30-year-old company operates its own data center in Germany, and there were growing demands internally and externally for solutions that needed to be geographically dispersed. And more generally, "we had objectives of being even more highly available," says Eric Mountain, Senior Expert, Distributed Systems at Amadeus. Among the company’s goals: to increase automation in managing its infrastructure, optimize the distribution of workloads, use data center resources more efficiently, and adopt new technologies more easily.

Solution

Mountain has been overseeing the company’s migration to Kubernetes, using OpenShift Container Platform, Red Hat’s enterprise container platform.

Impact

One of the first projects the team deployed in Kubernetes was the Amadeus Airline Cloud Availability solution, which helps manage ever-increasing flight-search volume. "It’s now handling in production several thousand transactions per second, and it’s deployed in multiple data centers throughout the world," says Mountain. "It’s not a migration of an existing workload; it’s a whole new workload that we couldn’t have done otherwise. [This platform] gives us access to market opportunities that we didn’t have before."

"We want multi-data center capabilities, and we want them for our mainstream system as well. We didn’t think that we could achieve them with our existing system. We need new automation, things that Kubernetes and OpenShift bring."

- Eric Mountain, Senior Expert, Distributed Systems at Amadeus IT Group

In his two decades at Amadeus, Eric Mountain has been the migrations guy.

Back in the day, he worked on the company’s move from Unix to Linux, and now he’s overseeing the journey to cloud native. "Technology just keeps changing, and we embrace it," he says. "We are celebrating our 30 years this year, and we continue evolving and innovating to stay cost-efficient and enhance everyone’s travel experience, without interrupting workflows for the customers who depend on our technology."

That was the challenge that Amadeus—which provides IT solutions to the travel industry around the world, from flight searches to hotel bookings to customer feedback—faced in 2014. The technology team realized it was in need of a new platform for the 5,000 services supported by its service-oriented architecture.

The tipping point occurred when they began receiving many requests, internally and externally, for solutions that needed to be geographically outside the company’s main data center in Germany. "Some requests were for running our applications on customer premises," Mountain says. "There were also new services we were looking to offer that required response time to the order of a few hundred milliseconds, which we couldn’t achieve with transatlantic traffic. Or at least, not without eating into a considerable portion of the time available to our applications for them to process individual queries."

More generally, the company was interested in leveling up on high availability, increasing automation in managing infrastructure, optimizing the distribution of workloads and using data center resources more efficiently. "We have thousands and thousands of servers," says Mountain. "These servers are assigned roles, so even if the setup is highly automated, the machine still has a given role. It’s wasteful on many levels. For instance, an application doesn’t necessarily use the machine very optimally. Virtualization can help a bit, but it’s not a silver bullet. If that machine breaks, you still want to repair it because it has that role and you can’t simply say, ‘Well, I’ll bring in another machine and give it that role.’ It’s not fast. It’s not efficient. So we wanted the next level of automation."

"We hope that if we build on what others have built, what we do might actually be upstream-able. As Kubernetes and OpenShift progress, we see that we are indeed able to remove some of the additional layers we implemented to compensate for gaps we perceived earlier."

While mainly a C++ and Java shop, Amadeus also wanted to be able to adopt new technologies more easily. Some of its developers had started using languages like Python and databases like Couchbase, but Mountain wanted still more options, he says, "in order to better adapt our technical solutions to the products we offer, and open up entirely new possibilities to our developers." Working with recent technologies and cool new things would also make it easier to attract new talent.

All of those needs led Mountain and his team on a search for a new platform. "We did a set of studies and proofs of concept over a fairly short period, and we considered many technologies," he says. "In the end, we were left with three choices: build everything on premise, build on top of Kubernetes whatever happens to be missing from our point of view, or go with OpenShift and build whatever remains there."

The team decided against building everything themselves—though they’d done that sort of thing in the past—because "people were already inventing things that looked good," says Mountain.

Ultimately, they went with OpenShift Container Platform, Red Hat’s Kubernetes-based enterprise offering, instead of building on top of Kubernetes because "there was a lot of synergy between what we wanted and the way Red Hat was anticipating going with OpenShift," says Mountain. "They were clearly developing Kubernetes, and developing certain things ahead of time in OpenShift, which were important to us, such as more security."

The hope was that those particular features would eventually be built into Kubernetes, and, in the case of security, Mountain feels that has happened. "We realize that there’s always a certain amount of automation that we will probably have to develop ourselves to compensate for certain gaps," says Mountain. "The less we do that, the better for us. We hope that if we build on what others have built, what we do might actually be upstream-able. As Kubernetes and OpenShift progress, we see that we are indeed able to remove some of the additional layers we implemented to compensate for gaps we perceived earlier."

"It’s not a migration of an existing workload; it’s a whole new workload that we couldn’t have done otherwise. [This platform] gives us access to market opportunities that we didn’t have before."

The first project the team tackled was one that they knew had to run outside the data center in Germany. Because of the project’s needs, "We couldn’t rely only on the built-in Kubernetes service discovery; we had to layer on top of that an extra service discovery level that allows us to load balance at the operation level within our system," says Mountain. They also built a stream dedicated to monitoring, which at the time wasn’t offered in the Kubernetes or OpenShift ecosystem. Now that Prometheus and other products are available, Mountain says the company will likely re-evaluate their monitoring system: "We obviously always like to leverage what Kubernetes and OpenShift can offer."

The second project ended up going into production first: the Amadeus Airline Cloud Availability solution, which helps manage ever-increasing flight-search volume and was deployed in public cloud. Launched in early 2016, it is "now handling in production several thousand transactions per second, and it’s deployed in multiple data centers throughout the world," says Mountain. "It’s not a migration of an existing workload; it’s a whole new workload that we couldn’t have done otherwise. [This platform] gives us access to market opportunities that we didn’t have before."

Having been through this kind of technical evolution more than once, Mountain has advice on how to handle the cultural changes. "That’s one aspect that we can tackle progressively," he says. "We have to go on supplying our customers with new features on our pre-existing products, and we have to keep existing products working. So we can’t simply do absolutely everything from one day to the next. And we mustn’t sell it that way."

The first order of business, then, is to pick one or two applications to demonstrate that the technology works. Rather than choosing a high-impact, high-risk project, Mountain’s team selected a smaller application that was representative of all the company’s other applications in its complexity: "We just made sure we picked something that’s complex enough, and we showed that it can be done."

"The bottom line is we want these multi-data center capabilities, and we want them as well for our mainstream system," he says. "And we don’t think that we can implement them with our previous system. We need the new automation, homogeneity, and scale that Kubernetes and OpenShift bring."

Next comes convincing people. "On the operations side and on the R&D side, there will be people who say quite rightly, ‘There is a system, and it works, so why change?’" Mountain says. "The only thing that really convinces people is showing them the value." For Amadeus, people realized that the Airline Cloud Availability product could not have been made available on the public cloud with the company’s existing system. The question then became, he says, "Do we go into a full-blown migration? Is that something that is justified?"

"The bottom line is we want these multi-data center capabilities, and we want them as well for our mainstream system," he says. "And we don’t think that we can implement them with our previous system. We need the new automation, homogeneity, and scale that Kubernetes and OpenShift bring."

So how do you get everyone on board? "Make sure you have good links between your R&D and your operations," he says. "Also make sure you’re going to talk early on to the investors and stakeholders. Figure out what it is that they will be expecting from you, that will convince them or not, that this is the right way for your company."

His other advice is simply to make the technology available for people to try it. "Kubernetes and OpenShift Origin are open source software, so there’s no complicated license key for the evaluation period and you’re not limited to 30 days," he points out. "Just go and get it running." Along with that, he adds, "You’ve got to be prepared to rethink how you do things. Of course making your applications as cloud native as possible is how you’ll reap the most benefits: 12 factors, CI/CD, which is continuous integration, continuous delivery, but also continuous deployment."

And while they explore that aspect of the technology, Mountain and his team will likely be practicing what he preaches to others taking the cloud native journey. "See what happens when you break it, because it’s important to understand the limits of the system," he says. Or rather, he notes, the advantages of it. "Breaking things on Kube is actually one of the nice things about it—it recovers. It’s the only real way that you’ll see that you might be able to do things."

Ancestry Case Study

Mon, 01 Jan 0001 00:00:00 +0000

CASE STUDY:

Digging Into the Past With New Technology

Company Ancestry Location Lehi, Utah Industry Internet Company, Online Services

Challenge

Ancestry, the global leader in family history and consumer genomics, uses sophisticated engineering and technology to help everyone, everywhere discover the story of what led to them. The company has spent more than 30 years innovating and building products and technologies that at their core, result in real and emotional human responses. Ancestry currently serves more than 2.6 million paying subscribers, holds 20 billion historical records, 90 million family trees and more than four million people are in its AncestryDNA network, making it the largest consumer genomics DNA network in the world. The company's popular website, ancestry.com, has been working with big data long before the term was popularized. The site was built on hundreds of services, technologies and a traditional deployment methodology. "It's worked well for us in the past," says Paul MacKay, software engineer and architect at Ancestry, "but had become quite cumbersome in its processing and is time-consuming. As a primarily online service, we are constantly looking for ways to accelerate to be more agile in delivering our solutions and our products."

Solution

The company is transitioning to cloud native infrastructure, using Docker containerization, Kubernetes orchestration and Prometheus for cluster monitoring.

Impact

"Every single product, every decision we make at Ancestry, focuses on delighting our customers with intimate, sometimes life-changing discoveries about themselves and their families," says MacKay. "As the company continues to grow, the increased productivity gains from using Kubernetes has helped Ancestry make customer discoveries faster. With the move to Dockerization for example, instead of taking between 20 to 50 minutes to deploy a new piece of code, we can now deploy in under a minute for much of our code. We’ve truly experienced significant time savings in addition to the various features and benefits from cloud native and Kubernetes-type technologies."

"At a certain point, you have to step back if you're going to push a new technology and get key thought leaders with engineers within the organization to become your champions for new technology adoption. At training sessions, the development teams were always the ones that were saying, 'Kubernetes saved our time tremendously; it's an enabler. It really is incredible.'"

- PAUL MACKAY, SOFTWARE ENGINEER AND ARCHITECT AT ANCESTRY

It started with a Shaky Leaf.

Since its introduction a decade ago, the Shaky Leaf icon has become one of Ancestry's signature features, which signals to users that there's a helpful hint you can use to find out more about your family tree.

So when the company decided to begin moving its infrastructure to cloud native technology, the first service that was launched on Kubernetes, the open source platform for managing application containers across clusters of hosts, was this hint system. Think of it as Amazon's recommended products, but instead of recommending products the company recommends records, stories, or familial connections. "It was a very important part of the site," says Ancestry software engineer and architect Paul MacKay, "but also small enough for a pilot project that we knew we could handle in a very appropriate, secure way."

And when it went live smoothly in early 2016, "our deployment time for this service literally was cut down from 50 minutes to 2 or 5 minutes," MacKay adds. "The development team was just thrilled because we're focused on supplying a great experience for our customers. And that means features, it means stability, it means all those things that we need for a first-in-class type operation."

The stability of that Shaky Leaf was a signal for MacKay and his team that their decision to embrace cloud native technologies was the right one for the company. With a private data center, Ancestry built its website (which launched in 1996) on hundreds of services and technologies and a traditional deployment methodology. "It worked well for us in the past, but the sum of the legacy systems became quite cumbersome in its processing and was time-consuming," says MacKay. "We were looking for other ways to accelerate, to be more agile in delivering our solutions and our products."

"And when it [Kubernetes] went live smoothly in early 2016, 'our deployment time for this service literally was cut down from 50 minutes to 2 or 5 minutes,' MacKay adds. 'The development team was just thrilled because we're focused on supplying a great experience for our customers. And that means features, it means stability, it means all those things that we need for a first-in-class type operation.'"

That need led them in 2015 to explore containerization. Ancestry engineers had already been using technology like Java and Python on Linux, so part of the decision was about making the infrastructure more Linux-friendly. They quickly decided that they wanted to go with Docker for containerization, "but it always comes down to the orchestration part of it to make it really work," says MacKay.

His team looked at orchestration platforms offered by Docker Compose, Mesos and OpenStack, and even started to prototype some homegrown solutions. And then they started hearing rumblings of the imminent release of Kubernetes v1.0. "At the forefront, we were looking at the secret store, so we didn't have to manage that all ourselves, the config maps, the methodology of seamless deployment strategy," he says. "We found that how Kubernetes had done their resources, their types, their labels and just their interface was so much further advanced than the other things we had seen. It was a feature fit."

Plus, MacKay says, "I just believed in the confidence that comes with the history that Google has with containerization. So we started out right on the leading edge of it. And we haven't looked back since."

Which is not to say that adopting a new technology hasn't come with some challenges. "Change is hard," says MacKay. "Not because the technology is hard or that the technology is not good. It's just that people like to do things like they had done [before]. You have the early adopters and you have those who are coming in later. It was a learning experience on both sides."

Figuring out the best deployment operations for Ancestry was a big part of the work it took to adopt cloud native infrastructure. "We want to make sure the process is easy and also controlled in the manner that allows us the highest degree of security that we demand and our customers demand," says MacKay. "With Kubernetes and other products, there are some good solutions, but a little bit of glue is needed to bring it into corporate processes and governances. It's like having a set of gloves that are generic, but when you really do want to grab something you have to make it so it's customized to you. That's what we had to do."

Their best practices include allowing their developers to deploy into development stage and production, but then controlling the aspects that need governance and auditing, such as secrets. They found that having one namespace per service is useful for achieving that containment of secrets and config maps. And for their needs, having one container per pod makes it easier to manage and to have a smaller unit of deployment.

"The success of Ancestry's first deployment of the hint system on Kubernetes helped create momentum for greater adoption of the technology."

With that process established, the time spent on deployment was cut down to under a minute for some services. "As programmers, we have what's called REPL: read, evaluate, print, and loop, but with Kubernetes, we have CDEL: compile, deploy, execute, and loop," says MacKay. "It's a very quick loop back and a great benefit to understand that when our services are deployed in production, they're the same as what we tested in the pre-production environments. The approach of cloud native for Ancestry provides us a better ability to scale and to accommodate the business needs as work loads occur."

The success of Ancestry's first deployment of the hint system on Kubernetes helped create momentum for greater adoption of the technology. "Engineers like to code, they like to do features, they don't like to sit around waiting for things to be deployed and worrying about scaling up and out and down," says MacKay. "After a while the engineers became our champions. At training sessions, the development teams were always the ones saying, 'Kubernetes saved our time tremendously; it's an enabler; it really is incredible.' Over time, we were able to convince our management that this was a transition that the industry is making and that we needed to be a part of it."

A year later, Ancestry has transitioned a good number of applications to Kubernetes. "We have many different services that make up the rich environment that [the website] has from both the DNA side and the family history side," says MacKay. "We have front-end stacks, back-end stacks and back-end processing type stacks that are in the cluster."

The company continues to weigh which services it will move forward to Kubernetes, which ones will be kept as is, and which will be replaced in the future and thus don't have to be moved over. MacKay estimates that the company is "approaching halfway on those features that are going forward. We don't have to do a lot of convincing anymore. It's more of an issue of timing with getting product management and engineering staff the knowledge and information that they need."

"... 'I believe in Kubernetes. I believe in containerization. I think if we can get there and establish ourselves in that world, we will be further along and far better off being agile and all the things we talk about, and it'll go forward.'"

Looking ahead, MacKay sees Ancestry maximizing the benefits of Kubernetes in 2017. "We're very close to having everything that should be or could be in a Linux-friendly world in Kubernetes by the end of the year," he says, adding that he's looking forward to features such as federation and horizontal pod autoscaling that are currently in the works. "Kubernetes has been very wonderful for us and we continue to ride the wave."

That wave, he points out, has everything to do with the vibrant Kubernetes community, which has grown by leaps and bounds since Ancestry joined it as an early adopter. "This is just a very rough way of judging it, but on Slack in June 2015, there were maybe 500 on there," MacKay says. "The last time I looked there were maybe 8,500 just on the Slack channel. There are so many major companies and different kinds of companies involved now. It's the variety of contributors, the number of contributors, the incredibly competent and friendly community."

As much as he and his team at Ancestry have benefited from what he calls "the goodness and the technical abilities of many" in the community, they've also contributed information about best practices, logged bug issues and participated in the open source conversation. And they've been active in attending meetups to help educate and give back to the local tech community in Utah. Says MacKay: "We're trying to give back as far as our experience goes, rather than just code."

When he meets with companies considering adopting cloud native infrastructure, the best advice he has to give from Ancestry's Kubernetes journey is this: "Start small, but with hard problems," he says. And "you need a patron who understands the vision of containerization, to help you tackle the political as well as other technical roadblocks that can occur when change is needed."

With the changes that MacKay's team has led over the past year and a half, cloud native will be part of Ancestry's technological genealogy for years to come. MacKay has been such a champion of the technology that he says people have jokingly accused him of having a Kubernetes tattoo.

"I really don't," he says with a laugh. "But I'm passionate. I'm not exclusive to any technology; I use whatever I need that's out there that makes us great. If it's something else, I'll use it. But right now I believe in Kubernetes. I believe in containerization. I think if we can get there and establish ourselves in that world, we will be further along and far better off being agile and all the things we talk about, and it'll go forward."

He pauses. "So, yeah, I guess you can say I'm an evangelist for Kubernetes," he says. "But I'm not getting a tattoo!"

蚂蚁金服案例研究

Mon, 01 Jan 0001 00:00:00 +0000

挑战

资源类型

Configuration

`Configuration`

Configuration 为 EventRateLimit 准入控制器提供配置数据。

字段	描述
`apiVersion` string	`eventratelimit.admission.k8s.io/v1alpha1`
`kind` string	`Configuration`
`limits` [必需] `[]Limit`	`limits` 是为所接收到的事件查询设置的限制。可以针对服务器端接收到的事件设置限制，按逐个名字空间、逐个用户、或逐个来源+对象组合的方式均可以。至少需要设置一种限制。

`Limit`

出现在：

GolfNow Case Study

Mon, 01 Jan 0001 00:00:00 +0000

CASE STUDY:

Saving Time and Money with Cloud Native Infrastructure

Company GolfNow Location Orlando, Florida Industry Golf Industry Technology and Services Provider

Challenge

A member of the NBC Sports Group, GolfNow is the golf industry’s technology and services leader, managing 10 different products, as well as the largest e-commerce tee time marketplace in the world. As its business began expanding rapidly and globally, GolfNow’s monolithic application became problematic. "We kept growing our infrastructure vertically rather than horizontally, and the cost of doing business became problematic," says Sheriff Mohamed, GolfNow’s Director, Architecture. "We wanted the ability to more easily expand globally."

Solution

Turning to microservices and containerization, GolfNow began moving its applications and databases from third-party services to its own clusters running on Docker and Kubernetes.

Impact

The results were immediate. While maintaining the same capacity—and beyond, during peak periods—GolfNow saw its infrastructure costs for the first application virtually cut in half.

"With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally. We were basically wasting money and doubling the cost of our infrastructure."

- SHERIFF MOHAMED, DIRECTOR, ARCHITECTURE AT GOLFNOW

It’s not every day that you can say you’ve slashed an operating expense by half.

But Sheriff Mohamed and Josh Chandler did just that when they helped lead their company, GolfNow, on a journey from a monolithic to a containerized, cloud native infrastructure managed by Kubernetes.

A top-performing business within the NBC Sports Group, GolfNow is a technology and services company with the largest tee time marketplace in the world. GolfNow serves 5 million active golfers across 10 different products. In recent years, the business had grown so fast that the infrastructure supporting their giant monolithic application (written in C#.NET and backed by SQL Server database management system) could not keep up. "With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally," says Sheriff, GolfNow’s Director, Architecture. "Our costs were growing exponentially. And on top of that, we had to build a Disaster Recovery (DR) environment, which then meant we’d have to copy exactly what we had in our original data center to another data center that was just the standby. We were basically wasting money and doubling the cost of our infrastructure."

In moving just the first of GolfNow’s important applications—a booking engine for golf courses and B2B marketing platform—from third-party services to their own Kubernetes environment, "our bill went down drastically," says Sheriff.

The path to those stellar results began in late 2014. In order to support GolfNow’s global growth, the team decided that the company needed to have multiple data centers and the ability to quickly and easily re-route traffic as needed. "From there we knew that we needed to go in a direction of breaking things apart, microservices, and containerization," says Sheriff. "At the time we were trying to get away from C#.NET and SQL Server since it didn’t run very well on Linux, where everything container was running smoothly."

To that end, the team shifted to working with Node.js, the open-source, cross-platform JavaScript runtime environment for developing tools and applications, and MongoDB, the open-source database program. At the time, Docker, the platform for deploying applications in containers, was still new. But once the team began experimenting with it, Sheriff says, "we realized that was the way we wanted to go, especially since that’s the way the industry is heading."

"The team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, 'Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn’t have to pay extra money at all.'"

GolfNow’s dev team ran an "internal, low-key" proof of concept and were won over. "We really liked how easy it was to be able to pass containers around to each other and have them up and running in no time, exactly the way it was running on my machine," says Sheriff. "Because that is always the biggest gripe that Ops has with developers, right? ‘It worked on my machine!’ But then we started getting to the point of, ‘How do we make sure that these things stay up and running?’"

That led the team on a quest to find the right orchestration system for the company’s needs. Sheriff says the first few options they tried were either too heavy or "didn’t feel quite right." In late summer 2015, they discovered the just-released Kubernetes, which Sheriff immediately liked for its ease of use. "We did another proof of concept," he says, "and Kubernetes won because of the fact that the community backing was there, built on top of what Google had already done."

But before they could go with Kubernetes, NBC, GolfNow’s parent company, also asked them to comparison shop with another company. Sheriff and his team liked the competing company’s platform user interface, but didn’t like that its platform would not allow containers to run natively on Docker. With no clear decision in sight, Sheriff’s VP at GolfNow, Steve McElwee, set up a three-month trial during which a GolfNow team (consisting of Sheriff and Josh, who’s now Lead Architect, Open Platforms) would build out a Kubernetes environment, and a large NBC team would build out one with the other company’s platform.

"We spun up the cluster and we tried to get everything to run the way we wanted it to run," Sheriff says. "The biggest thing that we took away from it is that not only did we want our applications to run within Kubernetes and Docker, we also wanted our databases to run there. We literally wanted our entire infrastructure to run within Kubernetes."

At the time there was nothing in the community to help them get Kafka and MongoDB clusters running within a Kubernetes and Docker environment, so Sheriff and Josh figured it out on their own, taking a full month to get it right. "Everything started rolling from there," Sheriff says. "We were able to get all our applications connected, and we finished our side of the proof of concept a month in advance. My VP was like, ‘Alright, it’s over. Kubernetes wins.’"

The next step, beginning in January 2016, was getting everything working in production. The team focused first on one application that was already written in Node.js and MongoDB. A booking engine for golf courses and B2B marketing platform, the application was already going in the microservice direction but wasn’t quite finished yet. At the time, it was running in Heroku Compose and other third-party services—resulting in a large monthly bill.

"'The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven’t come from the Kubernetes world you wouldn’t believe me.' Sheriff puts it in these terms: 'Before Kubernetes I wasn’t sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I’ve been sleeping at night.'"

"The goal was to take all of that out and put it within this new platform we’ve created with Kubernetes on Google Compute Engine (GCE)," says Sheriff. "So we ended up building piece by piece, in parallel, what was out in Heroku and Compose, in our Kubernetes cluster. Then, literally, just switched configs in the background. So in Heroku we had the app running hitting a Compose database. We’d take the config, change it and make it hit the database that was running in our cluster."

Using this procedure, they were able to migrate piecemeal, without any downtime. The first migration was done during off hours, but to test the limits, the team migrated the second database in the middle of the day, when lots of users were running the application. "We did it," Sheriff says, "and again it was successful. Nobody noticed."

After three weeks of monitoring to make sure everything was running stable, the team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, "Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn’t have to pay extra money at all."

Not only were they saving money, but they were also saving time. "I had a meeting this morning about migrating some applications from one cluster to another," says Josh. "I spent about 2 hours explaining the process. The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven’t come from the Kubernetes world you wouldn’t believe me." Sheriff puts it in these terms: "Before Kubernetes I wasn’t sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I’ve been sleeping at night."

A small percentage of the applications on GolfNow have been migrated over to the Kubernetes environment. "Our Core Team is rewriting a lot of the .NET applications into .NET Core [which is compatible with Linux and Docker] so that we can run them within containers," says Sheriff.

Looking ahead, Sheriff and his team want to spend 2017 continuing to build a whole platform around Kubernetes with Drone, an open-source continuous delivery platform, to make it more developer-centric. "Now they’re able to manage configuration, they’re able to manage their deployments and things like that, making all these subteams that are now creating all these microservices, be self sufficient," he says. "So it can pull us away from applications and allow us to just make sure the cluster is running and healthy, and then actually migrate that over to our Ops team."

"Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. 'This is The Six Million Dollar Man of the cloud right now,' adds Josh. 'Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They’re faster, they’re more resilient.'"

And long-term, Sheriff has an even bigger goal for getting more people into the Kubernetes fold. "We’re actually trying to make this platform generic enough so that any of our sister companies can use it if they wish," he says. "Most definitely I think it can be used as a model. I think the way we migrated into it, the way we built it out, are all ways that I think other companies can learn from, and should not be afraid of."

The GolfNow team is also giving back to the Kubernetes community by open-sourcing a bot framework that Josh built. "We noticed that the dashboard user interface is actually moving a lot faster than when we started," says Sheriff. "However we realized what we needed was something that’s more of a bot that really helps us administer Kubernetes as a whole through Slack." Josh explains: "With the Kubernetes-Slack integration, you can essentially hook into a cluster and the issue commands and edit configurations. We’ve tried to simplify the security configuration as much as possible. We hope this will be our major thank you to Kubernetes, for everything you’ve given us."

Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. The lessons they’ve learned: "You’ve got to have buy-in from your boss," says Sheriff. "Another big deal is having two to three people dedicated to this type of endeavor. You can’t have people who are half in, half out." And if you don’t have buy-in from the get go, proving it out will get you there.

"This is The Six Million Dollar Man of the cloud right now," adds Josh. "Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They’re faster, they’re more resilient."

Haufe Group Case Study

Mon, 01 Jan 0001 00:00:00 +0000

CASE STUDY:

Paving the Way for Cloud Native for Midsize Companies

Company Haufe Group Location Freiburg, Germany Industry Media and Software

Challenge

Founded in 1930 as a traditional publisher, Haufe Group has grown into a media and software company with 95 percent of its sales from digital products. Over the years, the company has gone from having "hardware in the basement" to outsourcing its infrastructure operations and IT. More recently, the development of new products, from Internet portals for tax experts to personnel training software, has created demands for increased speed, reliability and scalability. "We need to be able to move faster," says Solution Architect Martin Danielsson. "Adapting workloads is something that we really want to be able to do."

Solution

Haufe Group began its cloud-native journey when Microsoft Azure became available in Europe; the company needed cloud deployments for its desktop apps with bandwidth-heavy download services. "After that, it has been different projects trying out different things," says Danielsson. Two years ago, Holger Reinhardt joined Haufe Group as CTO and rapidly re-oriented the traditional host provider-based approach toward a cloud and API-first strategy.

A core part of this strategy was a strong mandate to embrace infrastructure-as-code across the entire software deployment lifecycle via Docker. The company is now getting ready to go live with two services in production using Kubernetes orchestration on Microsoft Azure and Amazon Web Services. The team is also working on breaking up one of their core Java Enterprise desktop products into microservices to allow for better evolvability and dynamic scaling in the cloud.

Impact

With the ability to adapt workloads, Danielsson says, teams "will be able to scale down to around half the capacity at night, saving 30 percent of the hardware cost." Plus, shorter release times have had a major impact. "Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," he says. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days."

"Over the next couple of years, people won’t even think that much about it when they want to run containers. Kubernetes is going to be the go-to solution."

- Martin Danielsson, Solution Architect, Haufe Group

More than 80 years ago, Haufe Group was founded as a traditional publishing company, printing books and commentary on paper.

By the 1990s, though, the company’s leaders recognized that the future was digital, and to their credit, were able to transform Haufe Group into a media and software business that now gets 95 percent of its sales from digital products. "Among the German companies doing this, we were one of the early adopters," says Martin Danielsson, Solution Architect for Haufe Group.

And now they’re leading the way for midsize companies embracing cloud-native technology like Kubernetes. "The really big companies like Ticketmaster and Google get it right, and the startups get it right because they’re faster," says Danielsson. "We’re in this big lump of companies in the middle with a lot of legacy, a lot of structure, a lot of culture that does not easily fit the cloud technologies. We’re just 1,500 people, but we have hundreds of customer-facing applications. So we’re doing things that will be relevant for many companies of our size or even smaller."

Many of those legacy challenges stemmed from simply following the technology trends of the times. "We used to do full DevOps," he says. In the 1990s and 2000s, "that meant that you had your hardware in the basement. And then 10 years ago, the hype of the moment was to outsource application operations, outsource everything, and strip down your IT department to take away the distraction of all these hardware things. That’s not our area of expertise. We didn’t want to be an infrastructure provider. And now comes the backlash of that."

Haufe Group began feeling the pain as they were developing more new products, from Internet portals for tax experts to personnel training software, that have created demands for increased speed, reliability and scalability. "Right now, we have this break in workflows, where we go from writing concepts to developing, handing it over to production and then handing that over to your host provider," he says. "And then when things go bad we have no clue what went wrong. We definitely want to take back control, and we want to move a lot faster. Adapting workloads is something that we really want to be able to do."

Those needs led them to explore cloud-native technology. Their first foray into the cloud was doing deployments in Microsoft Azure, once it became available in Europe, for desktop products that had built-in download services. Hosting expenses for such bandwidth-heavy services were too high, so the company turned to the cloud. "After that, it has been different projects trying out different things," says Danielsson.

"We have been doing containers for the last two years, and we really got the hang of how they work," says Danielsson. "But it was always for development and test, never in production, because we didn’t fully understand how that would work. And to me, Kubernetes was definitely the technology that solved that."

Two years ago, Holger Reinhardt joined Haufe Group as CTO and rapidly re-oriented the traditional host provider-based approach toward a cloud and API-first strategy. A core part of this strategy was a strong mandate to embrace infrastructure-as-code across the entire software deployment lifecycle via Docker. Some experiments went further than others; German regulations about sensitive data proved to be a road block in moving some workloads to Azure and Amazon Web Services. "Due to our history, Germany is really strict with things like personally identifiable data," Danielsson says.

These experiments took on new life with the arrival of the Azure Sovereign Cloud for Germany (an Azure clone run by the German T-Systems provider). With the availability of Azure.de—which conforms to Germany’s privacy regulations—teams started to seriously consider deploying production loads in Docker into the cloud. "We have been doing containers for the last two years, and we really got the hang of how they work," says Danielsson. "But it was always for development and test, never in production, because we didn’t fully understand how that would work. And to me, Kubernetes was definitely the technology that solved that."

In parallel, Danielsson had built an API management system with the aim of supporting CI/CD scenarios, aspects of which were missing in off-the-shelf API management products. With a foundation based on Mashape’s Kong gateway, it is open-sourced as wicked.haufe.io. He put wicked.haufe.io to use with his product team.

Otherwise, Danielsson says his philosophy was "don’t try to reinvent the wheel all the time. Go for what’s there and 99 percent of the time it will be enough. And if you think you really need something custom or additional, think perhaps once or twice again. One of the things that I find so amazing with this cloud-native framework is that everything ties in."

Currently, Haufe Group is working on two projects using Kubernetes in production. One is a new mobile application for researching legislation and tax laws. "We needed a way to take out functionality from a legacy core and put an application on top of that with an API gateway—a lot of moving parts that screams containers," says Danielsson. So the team moved the build pipeline away from "deploying to some old, huge machine that you could deploy anything to" and onto a Kubernetes cluster where there would be automatic CI/CD "with feature branches and all these things that were a bit tedious in the past."

"Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," says Danielsson. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days."

It was a proof of concept effort, and the proof was in the pudding. "Everyone was really impressed at what we accomplished in a week," says Danielsson. "We did these kinds of integrations just to make sure that we got a handle on how Kubernetes works. If you can create optimism and buzz around something, it’s half won. And if the developers and project managers know this is working, you’re more or less done." Adds Reinhardt: "You need to create some very visible, quick wins in order to overcome the status quo."

The impact on the speed of deployment was clear: "Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," says Danielsson. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days."

The potential impact on cost was another bonus. "Hosting applications is quite expensive, so moving to the cloud is something that we really want to be able to do," says Danielsson. With the ability to adapt workloads, teams "will be able to scale down to around half the capacity at night, saving 30 percent of the hardware cost."

Just as importantly, Danielsson says, there’s added flexibility: "When we try to move or rework applications that are really crucial, it’s often tricky to validate whether the path we want to take is going to work out well. In order to validate that, we would need to reproduce the environment and really do testing, and that’s prohibitively expensive and simply not doable with traditional host providers. Cloud native gives us the ability to do risky changes and validate them in a cost-effective way."

As word of the two successful test projects spread throughout the company, interest in Kubernetes has grown. "We want to be able to support our developers in running Kubernetes clusters but we’re not there yet, so we allow them to do it as long as they’re aware that they are on their own," says Danielsson. "So that’s why we are also looking at things like [the managed Kubernetes platform] CoreOS Tectonic, Azure Container Service, ECS, etc. These kinds of services will be a lot more relevant to midsize companies that want to leverage cloud native but don’t have the IT departments or the structure around that."

In the next year and a half, Danielsson says the company will be working on moving one of their legacy desktop products, a web app for researching legislation and tax laws originally built in Java Enterprise, onto cloud-native technology. "We’re doing a microservice split out right now so that we can independently deploy the different parts," he says. The main website, which provides free content for customers, is also moving to cloud native.

"the execution of a strategy requires alignment of culture, structure and technology. Only if those three dimensions are aligned can you successfully execute a transformation into microservices and cloud-native architectures. And it is only then that the Cloud will pay the dividends in much faster speeds in product innovation and much lower operational costs."

But with these goals, Danielsson believes there are bigger cultural challenges that need to be constantly addressed. The move to new technology, not to mention a shift toward DevOps, means a lot of change for employees. "The roles were rather fixed in the past," he says. "You had developers, you had project leads, you had testers. And now you get into these really, really important things like test automation. Testers aren’t actually doing click testing anymore, and they have to write automated testing. And if you really want to go full-blown CI/CD, all these little pieces have to work together so that you get the confidence to do a check in, and know this check in is going to land in production, because if I messed up, some test is going to break. This is a really powerful thing because whatever you do, whenever you merge something into the trunk or to the master, this is going live. And that’s where you either get the people or they run away screaming." Danielsson understands that it may take some people much longer to get used to the new ways.

"Culture is nothing that you can force on people," he says. "You have to live it for yourself. You have to evangelize. You have to show the advantages time and time again: This is how you can do it, this is what you get from it." To that end, his team has scheduled daylong workshops for the staff, bringing in outside experts to talk about everything from API to Devops to cloud.

For every person who runs away screaming, many others get drawn in. "Get that foot in the door and make them really interested in this stuff," says Danielsson. "Usually it catches on. We have people you never would have expected chanting, ‘Docker Docker Docker’ now. It’s cool to see them realize that there is a world outside of their Python libraries. It’s awesome to see them really work with Kubernetes."

Ultimately, Reinhardt says, "the execution of a strategy requires alignment of culture, structure and technology. Only if those three dimensions are aligned can you successfully execute a transformation into microservices and cloud-native architectures. And it is only then that the Cloud will pay the dividends in much faster speeds in product innovation and much lower operational costs."

Image Policy API (v1alpha1)

Mon, 01 Jan 0001 00:00:00 +0000

资源类型

ImageReview

`ImageReview`

ImageReview 检查某个 Pod 中是否可以使用某些镜像。



字段 描述

apiVersion
string imagepolicy.k8s.io/v1alpha1
kind
string ImageReview
metadata

meta/v1.ObjectMeta



 
 标准的对象元数据。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

 
参阅 Kubernetes API 文档了解 metadata 字段的内容。


spec [必需]

ImageReviewSpec


 
 
 spec 中包含与被评估的 Pod 相关的信息。
 


JD.com Case Study
Mon, 01 Jan 0001 00:00:00 +0000
Challenge

With more than 300 million active users and total 2017 revenue of more than $55 billion, JD.com is China's largest retailer, and its operations are the epitome of hyperscale. For example, there are more than a trillion images in JD.com's product databases—with 100 million being added daily—and this enormous amount of data needs to be instantly accessible. In 2014, JD.com moved its applications to containers running on bare metal machines using OpenStack and Docker to "speed up the delivery of our computing resources and make the operations much simpler," says Haifeng Liu, JD.com's Chief Architect. But by the end of 2015, with tens of thousands of nodes running in multiple data centers, "we encountered a lot of problems because our platform was not strong enough, and we suffered from bottlenecks and scalability issues," says Liu. "We needed infrastructure for the next five years of development, now."


kube-apiserver Admission (v1)
Mon, 01 Jan 0001 00:00:00 +0000


资源类型

AdmissionReview

AdmissionReview


AdmissionReview 描述准入评审请求/响应。


字段 描述

apiVersion
string admission.k8s.io/v1
kind
string AdmissionReview
request

AdmissionRequest




request 描述准入请求的属性。



response

AdmissionResponse




response 描述准入响应的属性。





AdmissionRequest

出现在：

AdmissionReview



AdmissionRequest 描述准入请求的 admission.Attributes。



kube-apiserver Audit 配置（v1）
Mon, 01 Jan 0001 00:00:00 +0000


资源类型

Event
EventList
Policy
PolicyList

Event

出现在：

EventList



Event 结构包含可出现在 API 审计日志中的所有信息。


字段 描述

apiVersion
string audit.k8s.io/v1
kind
string Event
level [必需]

Level


 
 
 生成事件所对应的审计级别。
 


auditID [必需]

k8s.io/apimachinery/pkg/types.UID


 
 
 为每个请求所生成的唯一审计 ID。
 


kube-apiserver 配置 (v1)
Mon, 01 Jan 0001 00:00:00 +0000



v1 包中包含 API 的 v1 版本。


资源类型

AdmissionConfiguration
AuthorizationConfiguration
EncryptionConfiguration

AdmissionConfiguration


AdmissionConfiguration 为准入控制器提供版本化的配置。


字段 描述

apiVersion
string apiserver.config.k8s.io/v1
kind
string AdmissionConfiguration
plugins

[]AdmissionPluginConfiguration


 
 
 plugins 字段允许为每个准入控制插件设置配置选项。
 




AuthorizationConfiguration

字段 描述

apiVersion
string apiserver.config.k8s.io/v1
kind
string AuthorizationConfiguration
authorizers [必需]

[]AuthorizerConfiguration




authorizers 是用于针对请求进行鉴权的鉴权组件的有序列表。
这类似于 --authorization-modes kube-apiserver 标志。
必须至少包含一个元素。



kube-apiserver 配置 (v1alpha1)
Mon, 01 Jan 0001 00:00:00 +0000



包 v1alpha1 包含 API 的 v1alpha1 版本。


资源类型

AdmissionConfiguration
AuthenticationConfiguration
AuthorizationConfiguration
EgressSelectorConfiguration
TracingConfiguration

TracingConfiguration

出现在：


KubeletConfiguration


TracingConfiguration




TracingConfiguration 为 OpenTelemetry 跟踪客户端提供了不同版本的配置。


字段 描述

endpoint

string


 
 
 采集器的端点，此组件将向其报告跟踪信息。
 连接不安全，目前不支持 TLS。
 推荐不设置，端点为 otlp grpc 默认值 localhost:4317。



kube-apiserver 配置 (v1beta1)
Mon, 01 Jan 0001 00:00:00 +0000



v1beta1 包是 v1beta1 版本的 API。


资源类型

AuthenticationConfiguration
AuthorizationConfiguration
EgressSelectorConfiguration
TracingConfiguration

TracingConfiguration

出现在：


KubeletConfiguration


TracingConfiguration


TracingConfiguration




TracingConfiguration 为 OpenTelemetry 跟踪客户端提供版本化的配置。


字段 描述

endpoint

string


 
 
 采集器的端点，此组件将向其报告跟踪信息。
 连接不安全，目前不支持 TLS。
 推荐不设置，端点为 otlp grpc 默认值 localhost:4317。
 


kube-controller-manager Configuration (v1alpha1)
Mon, 01 Jan 0001 00:00:00 +0000

资源类型

CloudControllerManagerConfiguration
LeaderMigrationConfiguration
KubeControllerManagerConfiguration

ClientConnectionConfiguration

出现在：


KubeSchedulerConfiguration


GenericControllerManagerConfiguration




ClientConnectionConfiguration 包含构建客户端的详细信息。


字段 描述

kubeconfig [必需]

string




kubeconfig 是指向 KubeConfig 文件的路径。



acceptContentTypes [必需]

string




acceptContentTypes 定义了客户端在连接服务器时发送的 Accept 请求头，
覆盖默认值 application/json。此字段将控制特定客户端与服务器之间的所有连接。



kube-proxy 配置 (v1alpha1)
Mon, 01 Jan 0001 00:00:00 +0000


资源类型

KubeProxyConfiguration

FormatOptions

出现在：

LoggingConfiguration



`FormatOptions` 包含不同日志格式的选项。


字段 描述

text [必需]

TextOptions




[Alpha] text 包含日志格式 "text" 的选项。
仅在启用了 `LoggingAlphaOptions` 特性门控时可用。



json [必需]

JSONOptions




[Alpha] JSON 包含日志格式 "json" 的选项。
仅在启用了 `LoggingAlphaOptions` 特性门控时可用。



kube-scheduler 配置 (v1)
Mon, 01 Jan 0001 00:00:00 +0000


资源类型

DefaultPreemptionArgs
DynamicResourcesArgs
InterPodAffinityArgs
KubeSchedulerConfiguration
NodeAffinityArgs
NodeResourcesBalancedAllocationArgs
NodeResourcesFitArgs
PodTopologySpreadArgs
VolumeBindingArgs

ClientConnectionConfiguration

出现在：

KubeSchedulerConfiguration


ClientConnectionConfiguration 中包含用来构造客户端所需的细节。

字段 描述

kubeconfig [必需]

string


 
 kubeconfig 字段为指向 KubeConfig 文件的路径。


acceptContentTypes [必需]

string


 
 
 acceptContentTypes 定义的是客户端与服务器建立连接时要发送的 Accept 头部，
 这里的设置值会覆盖默认值 "application/json"。此字段会影响某特定客户端与服务器的所有连接。
 


kubeadm 配置 (v1beta4)
Mon, 01 Jan 0001 00:00:00 +0000


概述
v1beta4 包定义 v1beta4 版本的 kubeadm 配置文件格式。
此版本改进了 v1beta3 的格式，修复了一些小问题并添加了一些新的字段。
从 v1beta3 版本以来的变更列表：


TODO https://github.com/kubernetes/kubeadm/issues/2890
使用 APIServer.ExtraEnvs、ControllerManager.ExtraEnvs、
Scheduler.ExtraEnvs、Etcd.Local.ExtraEnvs。
支持在 ClusterConfiguration 下控制平面组件中的定制环境变量。
ResetConfiguration API 类型在 v1beta4 中已得到支持。
用户可以为 kubeadm reset 指定 --config 文件来重置节点。


kubeadm 配置版本迁移

kubeadm v1.15.x 及更高版本可用于从 v1beta1 迁移到 v1beta2。
kubeadm v1.22.x 及更高版本不再支持 v1beta1 和更早的 API，但可用于从 v1beta2 迁移到 v1beta3。
kubeadm v1.27.x 及更高版本不再支持 v1beta2 和更早的 API。
TODO: https://github.com/kubernetes/kubeadm/issues/2890
添加可用于转换到 v1beta4 的版本



概述
v1beta3 包定义 v1beta3 版本的 kubeadm 配置文件格式。
此版本改进了 v1beta2 的格式，修复了一些小问题并添加了一些新的字段。
从 v1beta2 版本以来的变更列表：


已弃用的字段 "ClusterConfiguration.useHyperKubeImage" 现在被移除。
kubeadm 不再支持 hyperkube 镜像。
"ClusterConfiguration.dns.type" 字段已经被移除，因为 CoreDNS 是
kubeadm 所支持的唯一 DNS 服务器类型。
保存 Secret 信息的字段现在包含了 "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* 结构。



资源类型

Config

Config

Config 保存以给定用户身份构建连接到远程 Kubernetes 集群所需的信息 

字段 描述

apiVersion
string /v1
kind
string Config
kind

string




来自 pkg/api/types.go TypeMeta 的遗留字段。



apiVersion

string




来自 pkg/api/types.go TypeMeta 的遗留字段。



Kubelet CredentialProvider (v1)
Mon, 01 Jan 0001 00:00:00 +0000


资源类型

CredentialProviderRequest
CredentialProviderResponse

CredentialProviderRequest


CredentialProviderRequest 包含 kubelet 需要通过身份验证才能访问的镜像。
kubelet 将此请求对象通过 stdin 传递到插件。
通常，插件应优先使用所收到的 apiVersion 作出响应。


字段 描述

apiVersion
string credentialprovider.kubelet.k8s.io/v1
kind
string CredentialProviderRequest
image [必需]

string




image 是作为凭据提供程序插件请求的一部分所拉取的容器镜像。
这些插件可以选择解析镜像以提取获取凭据所需的任何信息。



kubelet 配置 (v1)
Mon, 01 Jan 0001 00:00:00 +0000


资源类型

CredentialProviderConfig

CredentialProviderConfig

CredentialProviderConfig 包含有关每个 exec 凭据提供程序的配置信息。
kubelet 从磁盘上读取这些配置信息，并根据 CredentialProvider 类型启用各个提供程序。

字段 描述

apiVersion
string kubelet.config.k8s.io/v1
kind
string CredentialProviderConfig
providers [必需]

[]CredentialProvider




providers 是一组凭据提供程序插件，这些插件会被 kubelet 启用。
多个提供程序可以匹配到同一镜像上，这时，来自所有提供程序的凭据信息都会返回给 kubelet。
如果针对同一镜像调用了多个提供程序，则结果会被组合起来。如果提供程序返回的认证主键有重复，
列表中先出现的提供程序所返回的值将被首先尝试。



kubelet 配置 (v1alpha1)
Mon, 01 Jan 0001 00:00:00 +0000


资源类型

CredentialProviderConfig

CredentialProviderConfig

CredentialProviderConfig 包含有关每个 exec 凭据提供者的配置信息。
kubelet 从磁盘上读取这些配置信息，并根据 CredentialProvider 类型启用各个提供者。

字段 描述

apiVersion
string kubelet.config.k8s.io/v1alpha1
kind
string CredentialProviderConfig
providers [必需]

[]CredentialProvider



providers 是一组凭据提供者插件，这些插件会被 kubelet 启用。
多个提供者可以匹配到同一镜像上，这时，来自所有提供者的凭据信息都会返回给 kubelet。
如果针对同一镜像调用了多个提供者，则结果会被组合起来。如果提供者返回的认证主键有重复，
列表中先出现的提供者所返回的值将第一个被尝试使用。




ImagePullIntent


ImagePullIntent 是 kubelet 尝试拉取镜像的记录。



Kubelet 配置 (v1beta1)
Mon, 01 Jan 0001 00:00:00 +0000


资源类型

CredentialProviderConfig
KubeletConfiguration
SerializedNodeConfigSource

FormatOptions

出现在：

LoggingConfiguration



FormatOptions 包含为不同日志格式提供的选项。


字段 描述



text [必需]

TextOptions



 [Alpha] 文本包含用于记录 "text" 格式的选项。
仅当 LoggingAlphaOptions 特性门控被启用时可用。


kuberc (v1alpha1)
Mon, 01 Jan 0001 00:00:00 +0000


资源类型

Preference

Preference


Preference 存储 KubeRC 配置文件的元素


字段 描述

apiVersion
string kubectl.config.k8s.io/v1alpha1
kind
string Preference
overrides [必需]

[]CommandOverride




overrides 允许更改命令的默认标志值。
这对于用户不想每次明确设置标志时特别有用。



aliases [必需]

[]AliasOverride




aliases 允许为现有的 kubectl 命令定义命令别名，并可选择设置默认标志值。
如果别名与内置命令冲突，内置命令始终优先。
在 overrides 部分定义的标志覆盖不适用于同一命令的别名。
kubectl [ALIAS NAME] [USER_FLAGS] [USER_EXPLICIT_ARGS] 展开为：
kubectl [COMMAND] # 别名指向的内置命令
 [KUBERC_PREPEND_ARGS]
 [USER_FLAGS]
 [KUBERC_FLAGS] # 其余未由用户在 [用户标志] 中传递的标志
 [USER_EXPLICIT_ARGS]
 [KUBERC_APPEND_ARGS]
例如：


kuberc (v1beta1)
Mon, 01 Jan 0001 00:00:00 +0000


资源类型

Preference

Preference


Preference 存储 KubeRC 配置文件的元素。


字段 描述

apiVersion
string kubectl.config.k8s.io/v1beta1
kind
string Preference
defaults [必需]

[]CommandDefaults




defaults 允许更改命令的默认选项值。
这对于用户不想每次明确设置选项时特别有用。



aliases [必需]

[]AliasOverride




aliases 允许为现有的 kubectl 命令定义命令别名，并可选择设置默认选项值。
如果别名与内置命令冲突，内置命令始终优先。
在 defaults 部分定义的选项 overrides 不适用于同一命令的别名。
kubectl [ALIAS NAME] [USER_OPTIONS] [USER_EXPLICIT_ARGS] 展开为：
kubectl [COMMAND] # 别名指向的内置命令
 [KUBERC_PREPEND_ARGS]
 [USER_OPTIONS]
 [KUBERC_OPTIONS] # 其余未由用户在 [用户选项] 中传递的选项
 [USER_EXPLICIT_ARGS]
 [KUBERC_APPEND_ARGS]
例如：


Kubernetes 发布周期
Mon, 01 Jan 0001 00:00:00 +0000




此内容原文是自动生成的，链接可能无法正常访问。
文档的来源在这里。



针对发布里程碑的特性增强、Issue 和 PR
本文档重点是面向于那些需要创建针对特定发布里程碑的特性增强、问题或拉取请求的 Kubernetes 开发人员和贡献者。


Kubernetes 社区行为准则
Mon, 01 Jan 0001 00:00:00 +0000


Kubernetes 遵循
CNCF 行为准则。
有关 CNCF 行为准则的文本，请参阅
commit 71412bb02。


	

云原生计算基金会（CNCF）社区行为准则 1.3 版本
社区行为准则

作为 CNCF 社区的贡献者、维护者和参与者，我们努力建设一个开放和受欢迎的社区，我们承诺尊重所有上报
Issue、发布功能需求、更新文档、提交 PR 或补丁、参加会议活动以及其他社区和项目活动的贡献者和参与者。


Kubernetes 外部指标 (v1beta1)
Mon, 01 Jan 0001 00:00:00 +0000



v1beta1 包是 v1beta1 版本的外部指标 API。


资源类型

ExternalMetricValue
ExternalMetricValueList

ExternalMetricValue

出现在：

ExternalMetricValueList



ExternalMetricValue 是外部指标的一个度量值。
单个度量值由指标名称和一组字符串标签标识。
对于一个指标，可以有多个具有不同标签集的值。



Kubernetes 指标 (v1beta1)
Mon, 01 Jan 0001 00:00:00 +0000


v1beta1 包是 v1beta1 版本的指标 API。

资源类型

NodeMetrics
NodeMetricsList
PodMetrics
PodMetricsList

NodeMetrics

出现在：

NodeMetricsList


NodeMetrics 设置节点的资源用量指标。

字段 描述

apiVersion
string metrics.k8s.io/v1beta1
kind
string NodeMetrics
metadata

meta/v1.ObjectMeta


 
 标准的对象元数据。更多信息：
 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata


Kubernetes 自定义指标 (v1beta2)
Mon, 01 Jan 0001 00:00:00 +0000


v1beta2 包是 v1beta2 版本的 custom_metrics API。
资源类型

MetricListOptions
MetricValue
MetricValueList

MetricListOptions


MetricListOptions 用于按其标签选择算符来选择指标。

字段 描述

apiVersion
string custom.metrics.k8s.io/v1beta2
kind
string MetricListOptions
labelSelector

string


 


挑战








  案例分析：

 Squarespace: 借力 Kubernetes 提升效率和可靠性
 





 公司名  Squarespace     地址  纽约市，纽约州     行业  软件服务，网站构建平台





 
 
 挑战
 自从 2014 年，我们从 monolith 架构移植到微服务架构，
 “虽然解决了开发端的问题，但却带来了架构组的问题”，Squarespace 网站可靠性组的主任工程师 Kevin Lynch 说道。
 “5000 个 VM 主机上的部署过程，让每个人都举步维艰。”

 

 
 解决方案
 网站可靠性组开始尝试使用不同的容器编排平台，然后发现 Kubernetes “解决了我们所有的既有问题”，Lynch 说道。于是整个公司在 2016 年开始在自己的数据中心中运行 Kubernetes 集群。
 

 



影响
自从 Squarespace 开始全面使用 Kubernetes，伴随着网络技术栈的革新，部署时间大幅减少85%。
以前，他们的 VM 部署需要耗费半个小时；现在，Lynch 提到，“一个人可以生成一个模板应用，在五分钟内部署，并将实例容器化，并在模拟环境下运行。”正因为如此，“开发效率节省了大量的成本。”
他又补充道，“当我们开始用 Kubernetes 时，我们可能只有十几个微服务。而现在的任务栏里面已经有两倍多的微服务正在进行中。”
Kubernetes 也同样提升了可靠性：“如果一个节点宕掉，马上会重新调度一个新的节点，没有任何性能上的影响。”






 
 
 

“一旦你验证了 Kubernetes 可以解决一个问题，每个人都会立即着手解决其它的问题，无需你的布道。”


— Kevin Lynch，Squarespace 网站可靠性组的主任工程师
 



 
 从 2003 年宿舍起步， Squarespace 已经为数百万人提供了网站构建服务。

 

 但在幕后，公司的单体应用却让开发人员在平台创新上举步维艰。所以在 2014 年，公司决定”走微服务之路”，Kevin Lynch 提到，Squarespace 网站稳定性组的主任工程师。
 “但是我们还是一直在自己的 vCenter VMware 虚拟机[我们自己的数据中心]上部署应用。微服务解决了开发端的问题，但是让问题转变到了基础架构组这一边。我们在5000个虚拟机主机上的部署流程让每个人的开发效率都提高不起来。”

 

 在尝试过另外一个容器编排平台，“非常痛苦地拆解它”，Lynch 说道，我们组开始在 2016 年年中尝试 Kubernetes，发现它“能解决我们所有的问题”。
 将 Kubernetes 部署在数据中心，而非公有云上是我们最大的挑战，但在当时，并没有很多其它的公司会这么做。
 “我们必须要自己摸索出如何在自己的基础架构中部署它，我们也必须要将其和我们其它的应用做集成，”Lynch补充道。



 

 与此同时，Squarespace 的网络工程组也正在革新它们的网络技术栈，从传统的 L2 网络转变为 L3 脊叶网络架构。
 “” Lynch 说道，“它给了我们服务器直接通过架顶交换机通信的能力。我们使用 Calico 作为
 Kubernetes 的 CNI 网络插件”，
 因而，我们可以为每个 Kubernetes pod 分配 IP 地址，并将它们和其它仍在虚拟机中创建的服务无缝衔接。





 
 
 在尝试过另外一个容器编排平台，“非常痛苦地拆解它”，Lynch 说道，我们组开始在 2016 年年中尝试 Kubernetes，发现它“能解决我们所有的问题”。
 




 

 几个月的时间，它们就有了一个稳定的集群供内部使用，并开始在生产环境下使用 Kubernetes。
 他们同时还在自己的云原生技术栈中用到了 Zipkin 和 CNCF 项目 Prometheus and fluentd 。
 “我们换到 Kubernetes，就像进入了一个新世界，我们也同时改进了其它的工具，” Lynch 说道。“它让我们简化了流程，因而，我们才能更加方便地从模板中创建整个微服务项目，生成代码和部署管道，生成 Docker 文件，
 并迅速地将可用的、可部署的项目发布到 Kubernetes 集群上。”在 Dev/QA/Stage/Prod 不同环境间的部署也变得 “异常的简单，” Lynch 补充道。
 “现在，环境间的配置差异变得很小。”




 

 而且整个部署过程只需要五分钟，和虚拟机部署相比，几乎节约了 85% 的时间。
 “从端到端可能要半个小时，这还没有考虑可能需要基础架构工程师来做这方面的工作，因而，也还有一些业务上的延时。”



 

 部署变快之后，“开发效率节省了大量的成本，” Lynch 提到，“我们有个组想要实现新的文件存储服务，他们就径直和我们的存储后来做了集成，而不需要我们的参与”，这在采用 Kubernetes 之前是不可想象的。
 他又补充道：“在我们开始 Kubernetes 项目时，我们可能只有十几个微服务。而现在的任务栏里面已经有两倍多的微服务正在进行中。”






 
 

 “我们换到 Kubernetes，就像进入了一个新世界....它让我们简化了流程，因而，我们才能更加方便地从模板中创建整个微服务项目，”
 Lynch 说道。整个部署过程只需要五分钟，和虚拟机部署相比，几乎节约了 85% 的时间。
 




 

 同样在应用程序的可靠性方面也有积极的影响。“当我们在部署虚拟机时，我们需要工具来保障服务散布在机架间，可以承受失败，”他说道，“Kubernetes 正好可以做到这一点。如果节点宕掉，可以马上重新调度，没有性能影响。”



 

 另一个很大的好处就是扩缩容。“按照我们使用 VMware 的方式，扩缩容好像不可能实现，”Lynch 说道，“但现在，我们可以直接通过 Kubernetes 加入合适的扩缩容功能，然后，随着需求的增加而扩容。开箱即用！”



 

 针对刚开始使用 Kubernetes 的人，Lynch 说他最后的建议就是“快速失败”：“一旦计划后，马上执行。Kubernetes 真的是非常适合快速实验，看看是否可行。”




 
 

 “当我们在部署虚拟机时，我们需要工具来保障服务散布在机架间，可以承受失败，”他说道，“Kubernetes 正好可以做到这一点。如果节点宕掉，可以马上重新调度，没有性能影响。”

 



 

 Lynch 和他的小组正准备开源一些他们的工具，这些工具用来延展 Kubernetes，将其作为 API 使用。
 第一个工具在 pod 将依赖应用作为容器注入。
 “当你在发布应用时，常常需要一系列的依赖应用，例如，日志用的 fluentd，” 他解释道。
 有了这个工具，开发人员就不需要担心配置了。




 

 自此之后，Squarespace 所有新的微服务都将直接部署到 Kubernetes 上，而最终的目标是要扩大到所有的服务上。
 现在已经有四分之一的服务已经移植完。“我的单体应用将是最后一个被移植的，仅仅是以为它太大、太复杂，”Lynch 说道。
 “但现在我已经看到其它的服务已经被移植到 Kubernetes 上，例如文件存储服务。有人解决了，而且并不复杂。
 所以我坚信如果我们着手解决它，很可能回避我们所担心的要轻松许多。也许我应该接受自己的建议，“快速失败”！”






WebhookAdmission 配置 (v1)
Mon, 01 Jan 0001 00:00:00 +0000



此 API 的版本是 v1。


资源类型

WebhookAdmission

WebhookAdmission


WebhookAdmission 为 Webhook 准入控制器提供配置信息。


字段 描述

apiVersion
string apiserver.config.k8s.io/v1
kind
string WebhookAdmission
kubeConfigFile [必需]

string




字段 kubeConfigFile 包含指向 kubeconfig 文件的路径。



Windows 调试技巧
Mon, 01 Jan 0001 00:00:00 +0000




工作节点级别排障


我的 Pod 都卡在 “Container Creating” 或者不断重启


Yahoo! Japan
Mon, 01 Jan 0001 00:00:00 +0000



阿迪达斯案例研究
Mon, 01 Jan 0001 00:00:00 +0000




 案例研究: 

 使小型分布式团队轻松部署





 公司 Buffer     位置  全球     行业  社交媒体技术公司





 
 


挑战
 Buffer 拥有一支80人的分布式团队，他们遍布全球近十几个时区。这样一个为代理商和营销人员提供社交媒体管理的公司，希望解决其“典型的单一庞大编码基数问题”，架构师 Dan Farrelly 这样说。“我们希望拥有一种流动性的基础架构，开发人员可以创建一个应用程序，可以根据需要部署并横向扩展它”。



 
解决方案
拥抱容器化，Buffer 将其基础设施从 AWS 上的 Elastic Beanstalk 迁移到由 Kubernetes 负责编排的 Docker 上。
 

 


影响
Farrelly 说，新系统“提高了我们将新变化进行部署和上线的能力”。“在自己的计算机上构建一些东西，并且知道它是可用的，这已经让事情简单了很多；而且我们的反馈周期现在也快了很多。”





 
 
“我们的团队能够直接使用既有的 Kubernetes 解决方案，这太棒了，而且它还在不断改进中。在意识到我们需要某些功能之前，它就出现在下一个版本中，或者在未来几个月内出现。

- DAN FARRELLY, BUFFER ARCHITECT
 





Dan Farrelly 用木工类比来解释他的公司 Buffer ，随着过去几年的发展，公司开始有这个问题。


“如果你自己做一张桌子，这很好！”公司的架构师说。“如果你请另一个人一起来做这个桌子，也许这个人可以在你抛光桌面时开始对腿进行抛光。但是，当你把第三个或第四个人带进来时，有人也许应该在另外一张桌子上工作。”需要处理越来越多不同的桌子，使 Buffer 走上了 Kubernetes 实现微服务和容器化的道路。




自2012年左右以来，Buffer 开始使用 Elastic Beanstalk ,这是亚马逊网络服务提供的网络基础设施编排服务。“我们部署了一个单一的PHP应用程序,它是在五六个环境中相同的应用程序，”Farrelly 说。“我们在很大程度上是一家产品驱动型的公司。”

这一切都是为了尽快给应用推出新功能并进行交付，如果能够正常运行，我们就不会花太多时间在上面。如果产品变得有点慢，我们可能会使用更快的服务器或只是增加一个实例，这些就已经足够了。然后继续前进。




但事情在2016年就到了头。随着应用提交修改的数量不断增加，Farrelly 和 Buffer 当时的首席技术官 Sunil Sadasivan 决定,是重新思考和构建其基础架构的时候了。“这是一个典型的单一庞大编码基数问题，”Farrelly说。公司的一些团队已经在开发环境中成功使用Docker，但在生产环境中，运行在 Docker 上的唯一应用程序是一个看不到真实用户流量的营销网站。他们希望在使用 Docker 上更进一步,下一步是寻找业务流程的选项。




 

Kubernetes 所做的所有事情都很好地适应了 Buffer 的需求。Farrelly 说：“我们希望拥有一种流动基础架构，开发人员可以创建一个应用程序，并在必要时部署并进行水平扩展。”“我们很快就使用一些脚本来设置几个测试集群，在容器中构建了一些小的概念性验证应用程序，并在一小时内部署了这些内容。我们在生产中运行容器方面经验很少。令人惊奇的是，我们能很快地用 Kubernetes 来处理。”
 




 
首先，他们考虑了Mesosphere、DC/OS和Amazon Elastic Container Service(他们的数据系统团队已经将其用于某些数据管道作业)。虽然他们对这些产品印象深刻，但他们最终还是与 Kubernetes 合作。
 
Farrelly 说：“我们的应用仍在 AWS 上运行，但是我们的团队通过 Kubernetes 无需手动配置即可创建服务并按需创建负载均衡器，这是使用 Kubernetes 的最佳入门体验。”“我们不需要考虑如何配置这个或那个,特别是相较于以前的 Elastic Beanstalk 环境，它为我们提供了一个自动配置的负载均衡器。我真的很喜欢 Kubernetes 对命令行的控制，只需要对端口进行配置，这样更加灵活。Kubernetes 是为做它所做的事情而设计的,所以它做得非常好。”



 
Kubernetes 所做的所有事情都很好地适应了 Buffer 的需求。Farrelly 说：“我们希望拥有一种流动基础架构，开发人员可以创建一个应用程序，并在必要时部署并进行水平扩展。”“我们很快就使用一些脚本来设置几个测试集群，在容器中构建了一些小的概念性验证应用程序，并在一小时内部署了这些内容。我们在生产中运行容器方面经验很少。令人惊奇的是,我们能很快地用 Kubernetes 来处理。”



 
最重要的是，它为公司最显著的特征之一提供了强大的解决方案：他们的远程团队分布在十几个不同的时区。Farrelly 说：“对我们的基础设施有深入了解的人生活在不同于我们相对集中的时区，而我们的大部分产品工程师都住在其他地方。”“因此，我们确实希望有人能够尽早掌握这套系统并利用好它，而不必担心部署工程师正在睡觉。否则，人们会为了一些东西必须得等待12到24小时左右。看到人们前进得更快，这真的很酷。”
 


 
Farrelly 说，Buffer 拥有相对较小的工程团队，只有 25 人，只有少数人从事基础设施工作，大多数前端开发人员都需要“一些强大的配置能力，以便部署任何他们想要的内容。”以前，“只有几个人知道如何用旧的方式设置一切。有了这个系统，审查文档变得很容易，并且能很快地看到效果。它降低了我们获取在开发环境中所需要一切的门槛。因为我们团队的人数不足以来构建所有这些工具或像其他大公司那样管理基础架构。”




 
 
Farrelly 说：“在我们以往的工作方式中，反馈循环流程要长得多，而且很微妙，因为如果你部署了某些东西，就存在破坏其他东西的风险。”“我们通过围绕 Kubernetes 构建的部署类型，能够及时检测 Bug 并修复它们，并使其部署得超快。这一秒正在修复漏洞，不一会就上线运行了。”
 




 
为了帮助解决这一问题，Buffer 开发人员编写了一个部署机器人，该机器人包装了 Kubernetes 部署过程，并且每个团队都可以使用。”“以前,我们的数据分析师会更新 Python 分析脚本，并且必须等待该团队的主管单击该按钮并部署它，”Farrelly 解释道。“现在，我们的数据分析师可以进行更改，输入 Slack 命令，‘/deploy’,它会立即进行部署。他们不需要等待这些缓慢的周转时间，他们甚至不知道它在哪里运行。这些都不重要了。
 


 
团队使用 Kubernetes 从头开始构建的第一个应用程序是一种新的图像大小调整服务。作为一种社交媒体管理工具，它允许营销团队通过发帖进行协作，并通过多个社交媒体配置文件和网络发送更新，Buffer 必须能够根据需要调整照片的大小，以满足不同的社交网络。Farrelly 说：“我们一直有这些拼凑在一起的解决方案。”
 


 
为了创建这项新服务，一位高级产品工程师被指派学习 Docker 和 Kubernetes，然后构建服务、测试、部署和监视服务，他能够相对快速地完成该服务。Farrelly说：“在我们以往的工作方式中，反馈循环流程要长得多，而且很微妙，因为如果你部署了某些东西，就存在破坏其他东西的风险。”“我们通过围绕 Kubernetes 构建的部署类型，能够及时检测 Bug 并修复它们，并使其部署得超快。这一秒正在修复漏洞,不一会就上线运行了。”
 


 
此外，与旧系统不同，他们只需一个命令就可以水平缩放内容。“当我们推出它,”Farrelly说，“我们可以预测，只需点击一个按钮。这使我们能够处理用户对系统的需求,并轻松扩展以处理它。”
 


 
他们以前不能做的另外一件事是金丝雀部署。Farrelly说，这种新功能“使我们在部署重大变革方面更加自信。”“以前，虽然进行很多测试但仍表现不错，但它也存在很多‘手指交叉’。这是每天运行 800000 次的东西，这是我们业务的核心。如果它不工作，我们的业务也无法运行。在 Kubernetes 世界中，我可以执行金丝雀部署以测试 1%，如果它不工作，我可以很快将其关闭。这使我们在快速部署和推出新更改的同时降低风险的能力得到了提高。”





 
 
Farrelly 说：“如果你想在生产中运行容器，拥有像谷歌内部使用的那种效果，那么 Kubernetes 就是一个很好的方法。”“我们是一个相对较小的团，实际上运行 Kubernetes，我们之前从来没来做过这样的事情。因此，它比你想象的更容易上手，这正是我想要告诉正在尝试使用它的人们的一件很重要的事。挑几个应用,把它们准备好,在机器上运行几个月,看看它能处理的怎么样。通过这种方式你可以学到很多东西。”
 




 
到 2016 年 10 月，Buffer 54% 的流量都通过其 Kubernetes 集群。Farrelly 说：“我们很多传统功能仍然运行正常，这些部分可能会转移到 Kubernetes 或永远留在我们的旧设置中。”但该公司当时承诺，“所有新的开发，所有新功能,将在Kubernetes上运行。”
 


 
2017年计划是将所有旧应用程序迁移到新的 Kubernetes 集群，并运行他们从旧基础架构中撤出的所有内容，以及他们正在另一个 Kubernetes 集群上开发的新服务。Farrelly 说：“我想为团队中的每个人带来我们早期服务的所有好处。”
 


 

对于 Buffer 的工程师来说，这是一个令人兴奋的过程。“每次部署新服务时，我们都需要弄清楚:好的，体系结构是什么？这些服务如何沟通？构建此服务的最佳方式是什么？”Farrelly说。“然后，我们使用 Kubernetes 的特性将所有部分聚合到一起。在学习如何设计面向服务的体系结构时，它使我们能够进行试验。以前，我们只是不能做到这一点。这实际上给了我们一个空白的白板，所以我们可以做任何我们想要的。”
 
 
部分空白是 Kubernetes 提供的灵活性，如果某一天 Buffer 可能想要或需要改变他的云服务。“这是与云无关的，所以也许有一天我们可以切换到谷歌或其他地方，”Farrelly 说。“我们非常依赖亚马逊的基础服务，但很高兴知道，如果我们需要的话，我们可以搬走。”
 


 
此时，Buffer 团队无法想象以任何其他方式运行其基础结构，他们很乐意传播这一信息。Farrelly 说：“如果你想在生产中运行容器，拥有像谷歌内部使用的那种效果，那么 Kubernetes 就是一个很好的方法。”“我们是一个相对较小的团队，实际上运行 Kubernetes，我们之前从来没来做过这样的事情。因此，它比你想象的更容易上手，这正是我想要告诉正在尝试使用它的人们的一件很重要的事。挑几个应用，把它们准备好，在机器上运行几个月，看看它能处理的怎么样。通过这种方式你可以学到很多东西。”
 






案例研究：IBM
Mon, 01 Jan 0001 00:00:00 +0000



  案例研究：
 在 Kubernetes 上使用 Notary 和 TUF 建立镜像信任服务




 公司  IBM     位置  阿蒙克， 纽约     行业  云计算





 
 挑战
 
IBM Cloud 提供公共、私有和混合云功能，包括基于 OpenWhisk 的服务 （FaaS）、托管于 Kubernetes 和容器，以及 Cloud Foundry 服务 （PaaS） 的各种运行时。这些运行时与公司企业技术（如 MQ 和 DB2、其现代人工智能 （AI） Watson 和数据分析服务）的强大功能相结合。IBM Cloud 用户可以使用其目录中 170 多个不同云原生服务的功能，包括 IBM 的气象公司 API 和数据服务等功能。在 2017 年后期，IBM 云容器托管团队希望构建镜像信任服务。


 解决方案
 
2018 年 2 月，这项新服务在 IBM 云中公开发布。IBM 云容器托管团队的软件开发者 Michael Hough 说，名为 Portieris 的镜像信任服务完全基于 Cloud Native Computing Foundation (CNCF) 的开源项目 Notary。Portieris 是 Kubernetes 的准入控制器，用于强制执行适当的信任等级。用户可以为每个 Kubernetes 命名空间或在集群级别创建镜像安全策略，并为不同的镜像强制实施不同级别的信任。Portieris 是 IBM 信任内容的关键部分，因为它使用户能够从 IKS 集群中使用公司的 Notary。产品是 Notary 服务器在 IBM 的云中运行，然后 Portieris 在 IKS 集群内运行。这使用户能够让 IKS 集群验证他们加载容器的镜像是否包含他们期望的内容，而 Portieris 是允许 IKS 集群应用该验证的原因。

 

影响
 
IBM 打算提供基于 Kubernetes 的容器服务和镜像托管服务，目的是为其企业客户提供完全安全的端到端平台。Hough 说：“镜像签名是该产品的关键部分之一，我们的容器托管团队将 Notary 视为在当前 Docker 和容器生态系统中实现该功能的实际方式。”该公司以前没有提供镜像签名，Notary 是它用来实现该功能的工具。“我们有一个多租户 Docker 托管服务，具有私有镜像托管功能，” Hough 说。“ Docker 托管使用哈希值来确保镜像内容正确，并且数据在传输和静态时都进行了加密。但它没有提供任何保证谁推镜像。我们使用 Notary 来允许用户在其专用仓库命名空间中签名镜像（如果他们愿意的话）。”





 
 
 “我们将 CNCF 视为云原生开源的安全避难所，为成员项目（无论是原始供应商还是项目）提供稳定性、使用寿命和预期维护。”

- Michael Hough, IBM 容器托管团队软件开发人员
 



 
 Docker 已经创建了 Notary 项目作为 The Update Framework (TUF) 的实现，TUF 的此实现为 Docker 内容信任提供了功能。
 IBM 云容器托管团队的软件开发者 Michael Hough 说：“在 TUF 和 Notary 对 CNCF 做出了贡献后，我们发现它正在成为容器生态系统中镜像签名的实际标准。”



选择 Notary 的关键原因是它已经与 IBM 的容器托管正在使用的现有身份验证技术兼容。TUF 的设计也是如此，它不要求托管团队必须涉足密钥管理业务。他说，这两项都是“有吸引力的设计决定，证实了我们对 Notary 的选择是正确的。”



在 IBM Cloud 中引入 Notary 功能以实现镜像签名，可提高 IBM 云平台的安全性，“我们预计这将包括签署 IBM 官方镜像以及预期的有安全需求的企业客户，” Hough 说。与安全策略实现结合使用时，我们预计 CI/CD 管道中会更多地使用部署策略，以便根据镜像签名者对服务部署进行精细控制。

Hough 说，镜像签名的可用性“对于需要这种级别镜像来源和安全性的客户来说，是一个巨大的好处。”“借助我们的 IBM 云上的 Kubernetes 以及我们提供的许可控制器，它允许 IBM 服务以及 IBM 公共云的客户使用安全策略来控制服务部署。”



 
 
 镜像签名是我们 Kubernetes 容器服务的关键部分之一，我们的容器托管团队将 Notary 视为在当前 Docker 和容器生态系统中实现该功能的实际方式。

- Michael Hough, IBM 容器托管团队软件开发人员

 



 
现在，Notary 通常作为现有 IBM 云容器托管的一个组件在 IBM 的公共云中提供服务，因此它被部署为五个 IBM 云区域中的高可用服务。此高可用性部署在五个区域中的每个区域中各有三个实例，实现负载均衡与故障转移。Hough 说：“我们还将其部署到后端 IBM Cloudant 持久性存储服务，并随端到端 TLS 支持一起部署。”


 
IBM 团队创建并开源了名为 Portieris 的 Kubernetes 准入控制器，该控制器使用 Notary 签名信息与客户定义的安全策略相结合，以控制将镜像部署到集群中。“我们希望通过使用我们的 Notary 服务来推动 Portieris 的使用，” Hough 说。


 
IBM 在创建和支持开源基础（包括 CNCF）方面一直占据主导地位。IBM 开放技术副总裁 Todd Moore 是现任 CNCF 董事会主席，许多 IBM 员工活跃于 CNCF 成员项目中。



 
 
 “有新项目应对这些挑战，包括在 CNCF 内。我们一定会饶有兴趣地关注这些进步。我们发现 Notary 社区是一个积极友好的社区，对变化持开放态度，例如我们为持久存储添加的 CouchDB 后端。”

 - Michael Hough, IBM 容器托管团队软件开发人员
 


 

该公司已经使用的 CNCF 项目有 containerd，Envoy，Prometheus，gRPC，CNI，而且正在探索 SPIFFE 和 SPIRE 在未来的潜在可用性。



对于希望部署 Notary 或云原生基础架构的其他公司，Hough 有何建议？



“虽然对于云原生基础结构软件的许多领域也是如此，但我们发现，高可用性、多区域的 Notary 部署需要扎实的实现来处理证书管理和轮换，”他说。“有新项目应对这些挑战，包括在 CNCF 内。我们一定会饶有兴趣地关注这些进步。我们发现 Notary 社区是一个积极友好的社区，对变化持开放态度，例如我们为持久存储添加的 CouchDB 后端。”
 



案例研究：Nordstrom
Mon, 01 Jan 0001 00:00:00 +0000

挑战


Nordstrom 希望提高其技术运营的效率和速度，其中包括 Nordstrom.com 电子商务网站。与此同时，Nordstrom 技术公司正在寻找压缩技术运营成本的方法。


解决方案




 案例研究： 

 云原生基础设施让你的智能家居互联
 






 公司  Wink     位置  纽约，纽约州     行业  物联网平台






 

 挑战
 
构建低延迟、高度可靠的基础设施，为数百万互联智能家居设备、公司消费者中心、移动应用之间的通信提供服务，强调水平可扩展性，能够快速加密所有内容和强健的连接。
 


 解决方案
 
全面使用 Kubernetes-Docker-CoreOS 容器的 Linux 系统。



 

 
 影响
 
“美国最大的两家零售商 [Home Depot 和 Walmart] 正在使用和推广 Wink 品牌和硬件，” Wink 工程主管 Kit Klein 自豪地说，不过他补充道，“这确实带来了很大的压力。这不是普通的零售商客户像技术狂热者一样追求前沿技术。这些人每天都在想要一些行之有效的东西，并且不会容忍技术方面的借口。”这进一步证明了 Klein 对 Wink 团队所构建的基础设施有多大的信心。由于 Wink 80% 的工作量在 Kubernetes-Docker-CoreOS 的统一堆栈上运行，公司已使自己能够不断创新和改进其产品和服务。克莱因说，致力于这项技术“使得在基础设施之上的建设相对容易。”
 






 
 
“它不是专有的，它是完全开放的，它非常可移植。你可以跨不同的云提供商运行所有工作负载。你可以轻松地运行混合形式的 AWS，甚至引入你自己的数据中心。这就是在一个开源 Kubernetes-Docker-CoreOS 容器 Linux 系统上统一所有内容的好处。如果你只有一个 Linux 发行版/计算机映像进行验证，则具有巨大的安全优势。好处是巨大的，因为即省钱又省时间。

- KIT KLEIN, WINK 工程主管

 




 
 
打开一个灯泡需要多少人？

 
Kit Klein 拿出他的手机进行演示。只需轻扫几下，Wink 的工程主管打开由一家纽约公司开发的智能家居应用程序，然后轻触灯光按钮。“老实说，当你拿着手机，意味着你控制着灯光，”他说，“当你感觉到你的手指在屏幕上的压力，灯就打开了。开灯就和触觉反馈到你的大脑一样快。”


 
当然，只需一根手指，不到 200 毫秒即可打开灯，或锁上门或更换恒温器。但是，让 Wink 能够帮助消费者以如此快速和轻松的速度管理其互联智能家居产品的是一个复杂的云原生基础架构，Klein 和他的团队使用开源的 CoreOS 统一系统构建并继续开发专为集群部署设计的操作系统和 Kubernetes，Kubernetes 是一个开源平台，用于跨主机集群自动部署、扩展和操作应用程序容器，提供以容器为中心的基础结构。Klein 说：“当你拥有一个庞大而复杂的相互依赖的微服务网络，需要能够发现彼此，并且需要水平可伸缩和对故障的容忍度时，这就是真正优化的原因。”“很多人最终依靠一些大型云提供商提供的专有服务来执行某些操作，但通过采用 CoreOS/Kubernetes 获得的是可移植性，而不是依赖于固定的某人。你真的可以决定自己的命运。“”


 
事实上，Wink 做到了。公司的使命是使家庭互联无障碍，即对非技术业主来说，用户友好，价格合理，也许最重要的是，可靠。Klein 说：“如果你不相信，当你点击开关时就可以打开一盏灯，或者你在远处使用手机检查你的房子，但是反馈信息不准确，那么系统的便利性就会丧失。”这就是基础架构的用处。


 
Wink 是在 Quirky 公司孵化的，该公司开发众包产品。Wink 应用程序于 2013 年首次推出，当时，它只控制了少数消费类产品，如 Quirky 与 GE 合作生产的 PivotPower Strip。随着智能家居产品的激增，Wink 于 2014 年在全国的 Home Depot 商店推出。其第一个项目：可以与 Honeywell 和 Chamberlain 等十几个品牌的智能产品集成的平台。最大的挑战是构建基础设施，为信息中心和产品之间的所有这些通信提供服务，重点是最大限度地提高可靠性和最小化延迟。


 
Klein 说：“当我们最初推出时，我们正以非常快的速度尝试将第一个产品推向市场，即最低可行产品。”“很多时候，你走一条路，最终不得不回头尝试不同的东西。但是在这个特殊的情况下，我们预先做了许多工作，这导致我们作出了一个真正明智的决定，将其部署到使用 CoreOS 容器的 Linux 上。而且是在项目伊始时就这么做了。”

 



 
 
“...通过 CoreOS/Kubernetes 带来的可移植性，你可以不依赖于任何人。你真的可以决定自己的命运。”
 



 
 
关注第一：Wink 的产品需要连接到人们家中在防火墙后面的消费设备。Klein 解释道：“由于没有 URL 这样的端点，你甚至不需要知道防火墙后面打开了哪些端口。”“因此，你基本上需要唤醒这些设备，然后与你的系统通信，然后在云和设备之间打开实时、双向通信。持续的连接真的非常重要，因为你希望尽可能减少发送消息的开销，你永远不知道什么时候有人会开灯。”


 
使用 Wink Hub 的最早版本，当你决定打开或关闭灯光时，请求将发送到云，然后执行。Wink 软件的后续更新启用了本地控制，将许多设备的延迟缩短到大约 10 毫秒。但是，由于需要云支持的智能家居产品生态系统的集成，低延迟互联网连接仍然是一个关键的考虑因素。
 


 
“你基本上需要唤醒此设备，然后与你的系统通信，然后在云和设备之间打开实时、双向通信。持续的连接真的非常重要，你永远不知道什么时候有人会开灯。”
 
此外，Wink 还有其他要求：水平可扩展性、快速加密所有内容的能力、在出现问题时可以轻松恢复的连接。Klein 说：“从一开始的整个结构来看，我们决定提供基于套接字的安全服务。”“我们总是使用某种集群技术来部署我们的服务，因此我们决定，这东西将被容器化，在 Docker 上运行。”


 
当时，就在两年多前，Docker 还没有被广泛使用，但是正如 Klein 指出的，“技术前沿的人们当然理解它。我们开始研究现有的潜在技术。限制因素之一是我们需要部署多端口非 http/https 服务。它并不真正适合某些早期的集群技术。我们非常喜欢这个项目，最后在其它东西上使用了一段时间，但最初它过于针对 http 工作负载。”


 
Wink 的后端工程团队决定使用 Docker 化的工作负载后，就不得不就操作系统和容器编排平台做出决定。Klein 笑着说：“很明显，你不能只是启动容器，希望一切顺利。”“你需要有一个有用的系统，以便管理工作负载的分发位置。当容器不可避免地死亡或类似的东西，重新启动它，你得有一个负载平衡器。要拥有强大的基础设施，需要进行各种内部事务管理工作。”

 


 
 
 
Klein 笑着说：“很明显，你不能只是启动容器，希望一切顺利。”“你需要有一个有用的系统，以便管理工作负载的分发位置。当容器不可避免地死亡或类似的东西，重新启动它，你得有一个负载平衡器。要拥有强大的基础设施，需要进行各种内部事务管理工作。”
 
 


 
 
Wink 考虑直接在通用 Linux 发行版（需要安装工具来运行容器化工作负载）和集群管理系统如 Mesos（面向拥有较大团队的企业）的基础上构建，但最终将目光投向了使用 CoreOS 容器的 Linux。“一个容器优化的Linux分发系统正是我们需要的，”他说。“我们不必为了尝试采用 Linux 发行版之类的东西来安装所有内容而四处奔波。它有一个内置的容器编排系统，Fleet ，和一个易于使用的 API。它不像一些较重的解决方案那样具有丰富的功能，但我们意识到，在那一刻，这正是我们需要的。”


 
Wink 的核心（以及经过改进的应用程序）于 2014 年 7 月推出，并进行了短期部署，并在第一个月内将服务转移到 Docker 化的 CoreOS 上部署。自那时以来，他们几乎将基础设施的其他所有部分（从第三方云到云的集成迁移到其客户服务和支付门户）迁移到使用 CoreOS 容器的 Linux 集群上。


 
使用此设置确实需要一些额外的配置。Klein 说：“ Fleet 作为一个基本的容器编排系统确实很好，但它不负责服务实例之间的路由、配置共享、加密等。当然，所有这些功能层都可以实现，但如果你不想花费大量时间手动编写单元文件（当然没有人这样做），则需要创建一个工具来自动执行其中一些文件，我们做到了。”


 
Wink 在 2015 年推出并集成了 CoreOS 核心技术时，很快接受了 Kubernetes 容器集群管理器，正如所承诺的那样，它最终提供了 Wink 想要的功能，并计划构建这些功能。“如果不是 Kubernetes，我们很可能采用我们为所创建的自动化工具实现的逻辑和库，并将它用于更高级别的抽象和工具，这些抽象和工具可供命令行中的非 DevOps 工程师使用，以创建和管理集群，” Klein 说。“但 Kubernetes 完全没有必要这样做，并且由比我们在集群管理方面有经验更丰富的人编写和维护，因此更好。现在，估计 Wink 80% 的工作负载是在使用 CoreOS 容器的 Linux 之上的 Kubernetes 上运行。”

 


 
 
 
“同发展保持同步。了解决策原因。如果你了解项目背后的意图，从技术意图到某种哲学意图，那么它可以帮助你了解如何与这些系统和谐地构建系统，而不是试图与之对抗。”
 
 


 
 
Wink 的去向理由很明确：“它不是专有的，它是完全开放的，它真的很便携，” Klein 说，“它很可移植。你可以跨不同的云提供商运行所有工作负载。你可以轻松地运行混合 AWS，甚至引入你自己的数据中心。这就是在一个使用 Kubernetes-Docker-CoreOS 容器的 Linux 系统上统一所有内容的好处。如果你只有一个 Linux 发行版来尝试验证，则具有巨大的安全优势。好处是巨大的，因为既省钱又省时间。”
 
Klein 承认，每个技术决策都有权衡。他表示：“对一些人来说，尖端技术将非常可怕。”“为了利用这一优势，你确实必须跟上技术。你不能把它当作一个黑盒子。同发展保持同步。了解决策原因。如果你了解项目背后的意图，从技术意图到某种哲学意图，那么它可以帮助你了解如何与这些系统和谐地构建系统，而不是试图与之对抗。”
 
Wink 于 2015 年被 Flex 收购，目前控制着全国 230 万台联网设备。公司下一步怎么办？去年11月，一款新版的 “Wink Hub 2”上架，除 Home Depot 外，Walmart 商店还首次上市。Klein 自豪地说：“美国最大的两家零售商都正在使用和推广 Wink 品牌和硬件，”不过他补充道，“这确实带来了很大的压力。这不是普通的零售商客户像技术狂热者一样追求前沿技术。这些人每天都在想要一些行之有效的东西，并且不会容忍技术方面的借口。这进一步证明了 Klein 对 Wink 团队所构建的基础设施有多大的信心。”
 
Wink 的工程团队从早期起就呈指数级增长，在幕后，Klein 对 Wink 使用的机器学习感到非常兴奋。“我们构建了一个数据管道的容器化小段系统，这些部分对整个团队都是有益的，并且可以有多个输出，”他说。“这就像数据管道作为微服务。”同样，Klein 指出，在使用 CoreOS 容器的 Linux 和 Kubernetes 上运行统一的系统是未来的创新的主要驱动力。“你不是每次都在重新发明轮子，”他说。“你可以专注于业务进行开发。”




案例研究：Workiva
Mon, 01 Jan 0001 00:00:00 +0000

 
  案例研究：
 使用 OpenTracing 帮助查找瓶颈








 公司  Workiva     Location  艾姆斯，爱荷华州     行业  企业软件






 
 挑战
 
Workiva提供了一个基于云的平台，用于管理和报告业务数据。此 SaaS 产品 Wdesk 被 70% 以上的财富 500 强企业使用。随着公司从单体系统向更分散的基于微服务的系统转变，“我们有许多人在研究这个问题，他们都在不同的团队中，所以我们需要确定问题是什么，瓶颈在哪里，”高级软件架构师 MacLeod Broad 说。随着后端代码在 Google App Engine，Google Compute Engine，以及 Amazon Web Services 上运行，Workiva 需要一个还未被开发的跟踪系统。在准备公司首批使用 AWS 的产品时，Broad 的团队将新应用程序中构建的电子表格数据与 Workiva 现有系统上的旧应用程序中创建的文档相关联，该功能涉及“同步和链接”功能，从而发现了一个理想的跟踪用例：存在循环依赖关系，而优化通常证明是不影响整体速度的微优化。







 解决方案
 
Broad 的团队推出了与平台无关的分布式跟踪系统 OpenTracing，帮助他们找出瓶颈。


影响
 
现在在整个公司使用，OpenTracing 产生了立竿见影的效果。软件工程师 Michael Davis 报告说：“跟踪让我们能够立即了解如何改进我们的服务。通过查看每个调用的花费时间以及最常使用哪些调用的组合，我们能够在单个修复中将平均响应时间减少 95%（从 600ms 到 30ms）。”






 

使用 OpenTracing，我的团队能够查看跟踪，并针对其他团队提出优化建议，而无需查看他们的代码。
— MacLeod Broad, Workiva 高级软件架构师

 



 
去年秋天，MacLeod Broad 在 Workiva 的平台团队在准备该公司的首批产品之一，当遇到障碍时就使用 Amazon Web Services 。
 
早期，Workiva 的后端主要运行在Google App Engine上。但随着 Workiva 的 SaaS 产品，Wdesk，一种基于云的管理和报告业务数据平台，将客户群增长到财富 500 强公司的 70% 以上，情况发生了变化。“随着客户需求的增长和产品供应的扩大，我们开始利用更广泛的服务，如 Amazon Web Services 以及其他 Google Cloud Platform 服务，从而创建一个多供应商环境。”


有了这个新产品，具备“同步和链接”功能，通过它，数据“经历了一大堆服务，从新的电子表格系统[Amazon Aurora]到我们所谓的链接系统，然后通过 http 推送到我们现有的系统，然后进行一些计算，结果将传回新系统，”Broad 说。“我们当时进行优化是为了速度。我们认为做了这种极好的优化，然后它会变成一个微观优化，这并没有真正影响系统的整体速度。”



Broad 团队面临的挑战听起来可能为其他公司所熟悉，这些公司也从单体系统转向更分散的基于微服务的系统。Broad 说：“我们有许多人从事这方面的工作，他们都在不同的团队中，因此很难了解问题是什么以及瓶颈在哪里。”


 
“每个服务团队都经历着不同的架构迭代，很难了解每个团队系统中的实际内容，”他补充道。“我们有循环依赖关系，其中有三个或四个不同的服务团队不确定问题的真正位置，需要大量的来回沟通。因此，我们浪费了很多时间说，‘这个哪一部分比较慢？根据应用场景的不同，哪一部分有时很慢？随着时间推移，哪一部分会逐渐变慢？这个进程的哪一部分是异步的，因此，它是否长时间运行并不重要？我们在做的哪些是多余的，其中哪一部分是错误？’”





 
 
 “跟踪系统可以一目了然地解释体系结构，缩小性能瓶颈并归零，通常只是帮助指导高级别的调查。一眼就能做到这一点，比在会议或三天的调试中要快得多，而且比从来不找出问题得过且过要快得多。”
— MACLEOD BROAD, WORKIVA 高级软件架构师

 





简而言之，它是跟踪的理想用例。Broad 说：“跟踪系统可以一目了然地解释体系结构，缩小性能瓶颈并归零，通常只是帮助在高级别指导调查。”“一眼就能做到这一点，比在会议或三天的调试中要快得多，而且比从不找出问题得过且过要快得多。”



Workiva 的后端代码在 Google Compute Engine 、App Engine 和 AWS 上运行，Broad 知道他需要一个与平台无关的跟踪系统。“我们正在研究不同的追踪解决方案，”他说，“我们决定，由于市场似乎是一个不断发展的市场，我们不想被一个供应商卡住。因此，OpenTracing 似乎是避免供应商限制我们实际使用的后端的最简捷方法。”



Broad 说，一旦他们将 OpenTrace 引入到第一个用例中，“跟踪使得瓶颈所在位置变得非常明显。”尽管每个人都认为是 Workiva 的现有代码减缓了速度，但事实并非如此。Broad 说：“看起来现有代码速度很慢，只是因为它能够达到我们下一代服务的水平，而且它们需要很长时间才能处理所有这些请求。”“在瀑布图上，你可以看到每个请求在得到响应时所做的完全相同的工作。因此，对于被分页的每个响应，每个服务请求看起来都完全相同。然后，就不用费神去思考‘为什么它再次做所有这些工作？’”



使用 OpenTrace 的跟踪功能，“我的团队能够查看跟踪，并针对另一个团队提出优化建议，而无需查看他们的代码，”Broad 说。“我们命名跟踪的方式可以说明请求是执行 SQL 调用还是创建 RPC。因此，可以非常简单地说，‘好吧，我们知道它能处理所有这些请求。处理一次缓存一次。’我们基本上完成了。所有这些调用立即变成了亚秒级的调用。”







 

“我们正在研究不同的跟踪解决方案，我们决定使用 OpenTracing，由于市场似乎是一个不断发展的市场，我们不想被一个供应商卡住。因此，OpenTracing 似乎是避免供应商限制我们实际使用的后端的最简捷方法。”
— MACLEOD BROAD, WORKIVA 高级软件架构师

 




 
在第一个用例成功后，参与尝试的每个人都回去重新编排了他们的产品。跟踪功能已添加到几个更多的用例中。Broad 说：“我们希望尽早度过最初的实施难关，而不会让整个部门一起渡过难关。”“现在，许多团队在启动新服务时添加它。我们现在确实比以前更将推动采用。”



一些团队很快就赢了。软件工程师 Michael Davis 说：“跟踪让我们能够立即了解如何改进我们的（工作空间）服务。通过查看每个调用的花费时间以及最常使用哪些调用的组合，我们能够在单个修复中将平均响应时间减少 95%（从 600ms 到 30ms）”。



Workiva 的大部分主要产品现在都使用 OpenTracing 进行跟踪，将数据推送到 Google StackDriver。即使未完全使用跟踪功能的产品，也具有一些组件和库。



Broad 指出，由于一些工程师正在使用 App Engine，并且已经拥有平台的 Appstats 库分析性能的经验，因此他们不需要花太多时间才能习惯使用 OpenTracing。但其他人则有点不情愿。“我认为，使用 OpenTracing 的最大障碍是担心引入跟踪和 StackDriver 的成本会是多少，”他说。“人们也非常关心将中间件添加到他们正在处理的任何内容中。有关传递上下文以及如何完成这些工作的问题很常见。我们的许多 Go 开发人员对此都很好，因为他们已经以这样或那样的形式这样做了。我们的 Java 开发人员并不热衷于这样做，因为他们使用了其他不需要该功能的系统。”



但好处显然超过了人们的担忧，而今天，Workiva 的官方政策是使用追踪。

事实上，Broad 认为跟踪天然符合 Workiva 现有的日志记录和指标系统。“这是我们在内部展示的方式，也是我们设计使用方式的方式，”他说。“我们的跟踪记录在与我们的应用指标和日志记录数据完全相同的机制中，并且它们被推送的方式完全相同。因此，在创建和记录所有数据时，我们对待这些数据完全一样。我们有一个内部库，用于日志记录、遥测、分析和跟踪。”






 
 
“跟踪让我们能够立即、可操作地洞察如何改进我们的（工作空间）服务。通过查看每个调用花费的时间以及最常使用哪些调用的组合，我们能够在单个修复中将平均响应时间减少 95%（从 600ms 到 30ms）。”
— Michael Davis, 软件工程师, Workiva 

 




 
对于 Workiva，OpenTracing 已成为一种重要工具，通过观察使用模式来聚焦最佳优化和确定什么是微观优化。Broad 说：“在某些项目中，我们经常假设客户正在做什么，我们针对这些疯狂的测试案例进行优化，这些案例的 1% 是同用户实际非常相符的。”“这样是非常有益的，‘好吧，我们在每个执行 X 的请求上添加 100 毫秒，如果最坏的情况，我们也只需要添加 100 毫秒，这仅发生在千分之一的请求或一百万个请求中的一个。’”



与许多其他公司不同，Workiva 还跟踪客户端。Broad 说：“对我们来说，用户体验很重要，如果 RPC 执行后还需要 5 秒才能在浏览器中显示，则 RPC 执行需要 100 毫秒就不重要了。”“因此，对于我们而言，这些客户端响应时间非常重要。我们跟踪它，看看加载的哪些部分需要很长时间。我们正在研究什么是“加载”的定义。是当你访问到它，还是当它被渲染时，或者当你可以与它交互时？我们计划使用跟踪来关注和更好地了解这些内容。”



这还需要根据外部和内部时钟的差异进行调整。“在时间纠正之前，这是非常恐怖的；我们的跟踪比什么都更具有误导性，” Broad 说。“因此，我们决定在响应标头上返回一个时间戳，然后让客户端根据该时间调整其时间，而不是更改其内部时钟，而只需计算客户端收到时响应时间的偏移量。如果最终出现一种不可能的情况，客户端的 RPC 调用持续了 210 毫秒但响应返回时间并不在这个范围内，那就必须得重新调用请求。”



Broad 对 OpenTracing 对公司产生的影响感到兴奋，并且也在展望该技术还能实现什么。一种可能性是使用跟踪实时更新文档。他表示：“使文档与现实保持同步是一项重大挑战。”“例如，我们刚刚运行了跟踪模拟，或者我们刚刚在此新部署上运行了烟雾测试，但是结果显示架构与文档不匹配。我们可以找到是谁的责任，并通知他们进行更新。这是我希望在未来通过追踪获得的功能之一。”






案例研究：Zalando
Mon, 01 Jan 0001 00:00:00 +0000


挑战




本文档描述了 Kubernetes 各个组件之间所支持的最大版本偏差。
特定的集群部署工具可能会对版本偏差添加额外的限制。


支持的版本
Kubernetes 版本以 x.y.z 表示，其中 x 是主要版本，
y 是次要版本，z 是补丁版本，遵循语义版本控制术语。
更多信息请参见
Kubernetes 版本发布控制。


变更性准入策略
Mon, 01 Jan 0001 00:00:00 +0000









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




本页概要介绍 MutatingAdmissionPolicy（变更性准入策略）。

MutatingAdmissionPolicies 允许你在有人向 Kubernetes API 写入变更时修改发生的操作。
如果你只想使用声明式策略来阻止对资源的某种更改（例如：保护平台命名空间不被删除），
ValidatingAdmissionPolicy
是更简单且更有效的替代方案。


补丁版本
Mon, 01 Jan 0001 00:00:00 +0000


Kubernetes 补丁版本的发布时间表和团队联系信息。
有关 Kubernetes 发布周期的常规信息，请参阅发布流程说明。

节奏
我们的补丁发布节奏通常是每月一次。
在 1.X 次要版本之后，最早的补丁版本通常要快一些（提前 1 到 2 周）。
严重错误修复可能会导致超出正常节奏而更快速的发布。
我们尽量避免在重要的节假日期间发布。


测试页面（中文版）
Mon, 01 Jan 0001 00:00:00 +0000


本页面服务于两个目的：

展示 Kubernetes 中文版文档中应如何使用 Markdown
提供一个测试用文档，用来测试可能影响所有文档的 HTML、CSS 和模板变更


标题级别
上面的标题是 H2 级别。页面标题（Title）会渲染为 H1。以下各节分别展示 H3-H6
的渲染结果。


调度 GPU
Mon, 01 Jan 0001 00:00:00 +0000









 
 特性状态：
 Kubernetes v1.26 [stable]
 
 



Kubernetes 支持使用设备插件来跨集群中的不同节点管理
AMD 和 NVIDIA GPU（图形处理单元），目前处于稳定状态。


调试运行中的 Pod
Mon, 01 Jan 0001 00:00:00 +0000



本页解释如何在节点上调试运行中（或崩溃）的 Pod。
准备开始



你的 Pod 应该已经被调度并正在运行中，
如果你的 Pod 还没有运行，请参阅调试 Pod。


发布管理员
Mon, 01 Jan 0001 00:00:00 +0000


“发布管理员（Release Managers）” 是一个总称，通过使用 SIG Release 提供的工具，
负责维护发布分支、标记发行版本以及创建发行版本的贡献者。
每个角色的职责如下所述。


联系方式

安全禁运政策


手册
发布管理员

成为发布管理员


发布管理员助理

成为发布管理员助理


SIG 发布负责人

首席
技术负责人




联系方式

 
 
 邮件列表
 Slack
 可见范围
 用法
 会员资格
 
 
 
 
 release-managers@kubernetes.io
 #release-management（频道）/@release-managers（用户组）
 公共
 发布管理员公开讨论
 所有发布管理员（包括助理和 SIG 主席）
 
 
 release-managers-private@kubernetes.io
 不适用
 私人
 拥有特权的发布管理员私人讨论
 发布管理员，SIG Release 负责人
 
 
 security-release-team@kubernetes.io
 #security-release-team（频道）/@security-rel-team（用户组）
 私人
 与安全响应委员会协调安全发布
 security-discuss-private@kubernetes.io, release-managers-private@kubernetes.io
 
 


安全禁运政策
发布的相关信息受到禁运，我们已经定义了有关如何设置这些禁运的政策。
更多信息请参考安全禁运政策。


说明
Mon, 01 Jan 0001 00:00:00 +0000


可以通过阅读与你的 Kubernetes 版本对应的
Changelog
找到发行版本说明。
在 GitHub
上查看 1.35 的变更日志。
或者，可以在以下位置在线搜索和筛选发行版本说明：relnotes.k8s.io。
在 relnotes.k8s.io
上查看 1.35 的筛选后的版本说明。


管理集群中的 TLS 认证
Mon, 01 Jan 0001 00:00:00 +0000



Kubernetes 提供 certificates.k8s.io API，可让你配置由你控制的证书颁发机构（CA）
签名的 TLS 证书。 你的工作负载可以使用这些 CA 和证书来建立信任。


管理巨页（HugePage）
Mon, 01 Jan 0001 00:00:00 +0000









 
 特性状态： 
 Kubernetes v1.14 [stable]（默认启用）


Kubernetes 支持在 Pod 应用中使用预先分配的巨页。本文描述了用户如何使用巨页，以及当前的限制。
准备开始

为了使节点能够上报巨页容量，Kubernetes
节点必须预先分配巨页。


华为案例分析
Mon, 01 Jan 0001 00:00:00 +0000



挑战



华为作为一个跨国企业，是世界上最大的电信设备制造商，拥有超过 18 万名员工。
为了支持华为在全球的快速业务发展，华为内部 IT 部门有 8 个数据中心，
这些数据中心在 10 万多台虚拟机上运行了 800 多个应用程序，为内部 18 万用户提供服务。
随着新应用程序的快速增长，基于虚拟机的应用程序管理和部署的成本和效率都成为业务敏捷性的关键挑战。
该公司首席软件架构师、开源社区总监侯培新表示：
“这是一个超大的分布式系统，因此我们发现，以更一致的方式管理所有任务始终是一个挑战。
我们希望进入一种更敏捷、更得体的实践”。



获取正在运行容器的 Shell
Mon, 01 Jan 0001 00:00:00 +0000


本文介绍怎样使用 kubectl exec 命令获取正在运行容器的 Shell。
准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。
建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。
如果你还没有集群，你可以通过 Minikube
构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：


客户端身份认证（Client Authentication） (v1)
Mon, 01 Jan 0001 00:00:00 +0000


资源类型

ExecCredential

ExecCredential

ExecCredential 由基于 exec 的插件使用，与 HTTP 传输组件沟通凭据信息。

字段 描述

apiVersion
string client.authentication.k8s.io/v1
kind
string ExecCredential
spec [必需]

ExecCredentialSpec


 
 字段 spec 包含由 HTTP 传输组件传递给插件的信息。


status

ExecCredentialStatus


 
 字段 status 由插件填充，包含传输组件与 API 服务器连接时需要提供的凭据。




Cluster

出现在：


客户端身份认证（Client Authentication）(v1beta1)
Mon, 01 Jan 0001 00:00:00 +0000


资源类型

ExecCredential

ExecCredential

ExecCredential 由基于 exec 的插件使用，与 HTTP 传输组件沟通凭据信息。

字段 描述

apiVersion
string client.authentication.k8s.io/v1beta1
kind
string ExecCredential

spec [必需]

ExecCredentialSpec


 
字段 spec 包含由 HTTP 传输组件传递给插件的信息。



status

ExecCredentialStatus


 
字段 status 由插件填充，包含传输组件与 API 服务器连接时需要提供的凭据。


扩展 Service IP 范围
Mon, 01 Jan 0001 00:00:00 +0000









 
 特性状态： 
 Kubernetes v1.33 [stable]（默认启用）


本文将介绍如何扩展分配给集群的现有 Service IP 范围。
准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。
建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。
如果你还没有集群，你可以通过 Minikube
构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：


审计
Mon, 01 Jan 0001 00:00:00 +0000



Kubernetes 审计（Auditing） 功能提供了与安全相关的、按时间顺序排列的记录集，
记录每个用户、使用 Kubernetes API 的应用以及控制面自身引发的活动。


使用 telepresence 在本地开发和调试服务
Mon, 01 Jan 0001 00:00:00 +0000


说明： 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循CNCF 网站指南，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读内容指南。

Kubernetes 应用程序通常由多个独立的服务组成，每个服务都在自己的容器中运行。
在远端的 Kubernetes 集群上开发和调试这些服务可能很麻烦，
需要在运行的容器上打开 Shell，
以运行调试工具。


手动轮换 CA 证书
Mon, 01 Jan 0001 00:00:00 +0000



本页展示如何手动轮换证书机构（CA）证书。
准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。
建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。
如果你还没有集群，你可以通过 Minikube
构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：


搜索结果
Mon, 01 Jan 0001 00:00:00 +0000



为 kubelet 配置证书轮换
Mon, 01 Jan 0001 00:00:00 +0000



本文展示如何在 kubelet 中启用并配置证书轮换。







 
 特性状态：
 Kubernetes v1.19 [stable]
 
 


准备开始


要求 Kubernetes 1.8.0 或更高的版本



概述
Kubelet 使用证书进行 Kubernetes API 的认证。
默认情况下，这些证书的签发期限为一年，所以不需要太频繁地进行更新。


为 Kubernetes 文档出一份力
Mon, 01 Jan 0001 00:00:00 +0000


本网站由 Kubernetes SIG Docs（文档特别兴趣小组）维护。
Kubernetes 项目欢迎所有贡献者（无论是新手还是经验丰富的贡献者）提供帮助！


下载 Kubernetes
Mon, 01 Jan 0001 00:00:00 +0000


Kubernetes 为每个组件提供二进制文件以及一组标准的客户端应用来引导集群或与集群交互。
像 API 服务器这样的组件能够在集群内的容器镜像中运行。
这些组件作为官方发布过程的一部分，也以容器镜像的形式提供。
所有二进制文件和容器镜像都可用于多种操作系统和硬件架构。


验证 IPv4/IPv6 双协议栈
Mon, 01 Jan 0001 00:00:00 +0000



本文分享了如何验证 IPv4/IPv6 双协议栈的 Kubernetes 集群。
准备开始


驱动程序对双协议栈网络的支持 (云驱动或其他方式必须能够为 Kubernetes 节点提供可路由的 IPv4/IPv6 网络接口)
一个能够支持双协议栈网络的
网络插件。
启用双协议栈集群



你的 Kubernetes 服务器版本必须不低于版本 v1.23.
 要获知版本信息，请输入 kubectl version.


验证准入策略（ValidatingAdmissionPolicy）
Mon, 01 Jan 0001 00:00:00 +0000









 
 特性状态：
 Kubernetes v1.30 [stable]
 
 



本页面提供验证准入策略（Validating Admission Policy）的概述。


什么是验证准入策略？
验证准入策略提供一种声明式的、进程内的替代方案来验证准入 Webhook。


用 Kubectl 调试 Kubernetes 节点
Mon, 01 Jan 0001 00:00:00 +0000



本页演示如何使用 kubectl debug 命令调试在 Kubernetes
集群上运行的节点。
准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。
建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。
如果你还没有集群，你可以通过 Minikube
构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

生产级别的容器编排系统 on Kubernetes

APIService

APIService

Babylon Case Study

Challenge

Solution

ConfigMap

ConfigMap

CustomResourceDefinition

CustomResourceDefinition

DeleteOptions

FlowSchema

FlowSchema

kubectl 介绍

命令分类

LocalSubjectAccessReview

LocalSubjectAccessReview

Pod

Pod

Service

Service

ServiceAccount

ServiceAccount

Binding

Binding

Booz Allen Case Study

Challenge

Solution

Bose Case Study

挑战

ComponentStatus

ComponentStatus

DeviceClass

DeviceClass

Endpoints

Endpoints

LabelSelector

LimitRange

LimitRange

Secret

Secret

SelfSubjectAccessReview

SelfSubjectAccessReview

TokenRequest

TokenRequest

Booking.com Case Study

Challenge

Solution

CSIDriver

CSIDriver

EndpointSlice

EndpointSlice

Event

Event

ListMeta

MutatingWebhookConfiguration

MutatingWebhookConfiguration

PodTemplate

PodTemplate

ResourceQuota

ResourceQuota

SelfSubjectRulesReview

SelfSubjectRulesReview

TokenReview

TokenReview

AppDirect Case Study

CASE STUDY: AppDirect: How AppDirect Supported the 10x Growth of Its Engineering Staff with Kubernetes

Challenge

Solution

Impact

With its end-to-end commerce platform for cloud-based products and services, AppDirect has been helping organizations such as Comcast and GoDaddy simplify the digital supply chain since 2009.

CertificateSigningRequest

证书签名请求 CertificateSigningRequest

CSINode

CSINode

Denso Case Study

Challenge

Ingress

Ingress

IPAddress

CASE STUDY:

AppDirect: How AppDirect Supported the 10x Growth of Its Engineering Staff with Kubernetes