Kubernetes的主要功能清单（v1.5版本）

2 年 ago

科, 雅

5 minutes

这篇文章是 Kubernetes Advent Calendar 2016 第13天的文章。正好在这篇文章发布的日期（12/13），Kubernetes v1.5.0被推出了。

我已经整理了一个包括开发中的功能在内的主要功能列表，涵盖到了Kubernetes在v1.5版本时不断进化和增加的功能。

可扩展性相关

聚类功能

Kubernetes的集群功能由主控组件(kube-apiserver, etcd, kube-scheduler, kube-controller-manager)和节点组件(kubelet, kube-proxy)组成。

在KubeCon 2016中，Marek Grabowski先生在一场名为”2000个节点以上：我们如何将Kubernetes扩展到60000个容器集群以及下一步计划”的演讲中提到了关于集群与节点数量的问题。有一份演讲资料整理了这些内容。

在Kubernetes的结构中，各种组件通过参考API服务器来进行处理，因此主要通过API服务器来实现可扩展性的提高。

根据《2000个及以上的节点》演示幻灯片，Kubernetes每个版本对应的节点数如下。

バージョン対応ノード数主な取り組みv1.0100内部の型変換(versioned -> unversioned)をreflectからコード生成にしたv1.1250APIサーバーのetcdのwatchを1キーにつき1watchにまとめるようにした(cacher層)v1.21,000kubemarkというベンチマークができたv1.32,000APIサーバーの通信で内部クライアントはjsonからprotobufを使うようになったv1.42,000
v1.5?etcd v2からv3への移行が予定されていたが見送りに

请参考

Kubernetes: コンテナが起動するまでの各コンポーネントの流れ

多个集群协同合作 (联合Kubernetes)

联邦Kubernetes是一种将多个Kubernetes集成在一起的功能。它也被称为Ubernetes（”uber-“是”超越”的意思前缀）。通过跨越云服务提供商（如AWS、GCP）和可用区域进行集群间的协作，可以提高可用性并扩展集群规模。该功能正在积极开发中，并且在v1.5版本中已经支持了Deployment、ConfigMap等资源。

@toshitanian先生所写的关于Kubernetes Federation的现状和未来的文章总结得非常出色。

以下仅提供一种中文的释义：
参考：提供加以借鉴和参考的信息或意见。

Federation User Guide

水平 Pod 自动缩放 (HorizontalPodAutoscaler) 应用程序

通过HorizontalPodAutoscaler功能，支持应用程序的水平自动扩展。该功能可以通过使用应用程序（Pod）的数量和CPU使用率等测量值来自动调整。除了默认提供的CPU使用率之外，还可以使用alpha功能来使用自定义的指标。

据了解，未来可能会考虑应用程序的垂直扩展功能。对于垂直扩展的必要性，Kubernetes的核心开发者Tim Hockin先生在2016年的KubeCon上发表的《几乎包括您想知道的有关资源调度的一切》详细阐述了相关内容。

参考一下

Vertical pod auto-sizer #10782

应用程序的部署和执行

提供应用程序的单元（Pod）

Pod是在Kubernetes上运行应用程序的最小单元，也是Kubernetes的基本资源。它由一个或多个共享同一进程空间、网络和存储的容器组成。这样一来，我们可以将辅助进程（如日志收集器）与应用程序一起部署为一个整体。

What is a pod?

应用程序的副本数管理(ReplicationController / ReplicaSet)

ReplicationController和ReplicaSet是用于管理应用程序（Pod）的副本数量的机制。它们以逼近用户期望的副本数量（期望状态）的方式来控制集群中运行的Pod数量。这种功能还实现了自动修复的机制。

ReplicationController和ReplicaSet目前几乎没有区别，只是ReplicationController这个名字较长，容易引起资源名中的controller混淆，因此产生了ReplicaSet。

请参考

Kubernetes: コンテナが起動するまでの各コンポーネントの流れ

滚动更新等部署管理 (Deployment)

部署是一种管理部署的机制，提供滚动更新和回滚功能。它在内部使用ReplicaSet，并通过创建新旧两个ReplicaSet并进行切换来进行滚动更新。

请参考

What is a Deployment?

状态集的管理（StatefulSet）

StatefulSet(v1.4以前被称为PetSet)是支持有状态应用的功能。与ReplicaSet不同的是，每个要管理的Pod都可以有独立的名称和状态。具体而言，当部署需要每个成员(Pod)都具有状态且需要识别的应用程序，例如etcd或zookeeper时，就会使用StatefulSet。

PetSet在正式推出前，人们在 issue #27430上讨论了将其更名为StatefulSet的原因。

可以借鉴

Kubernetes 1.3の変更点(予定)#PetSet(ステートフルアプリのサポート)の追加 (alpha)

节点级别的守护程序部署管理（DaemonSet）

DaemonSet是在集群的每个节点上运行特定守护程序的功能。例如，可以使用它来在每个节点上运行像ceph这样的存储守护程序，或者像fluentd这样的日志收集器，或者像linkerd这样的透明代理。

请参照以下内容并用中文写出同义句。只需要一种选项：

linkerd: RUNNING IN KUBERNETES WITH DAEMONSETS

工作批处理

Job是用于执行单个作业处理（具有明确结束的处理）的功能。

What is a job?

定期任务 (CronJob)

通过使用CronJob（在v1.4之前为ScheduledJob），可以执行基于cron的调度任务。

@koudaiiiさん的CronJob（定时作业）的文章写得很好。

网络服务提供

服务发现和负载均衡（服务/ KubeDNS / kube-proxy）

Service是一项提供集群内服务发现和负载均衡功能的服务。通过使用Label和Selector机制，Service可以选择Pod，并为其分配一个虚拟IP地址（ClusterIP），以实现对底层Pod集群的负载均衡。同时，Service还会自动在内部DNS（KubeDNS）中注册域名，提供服务发现功能。

负载均衡是通过每个节点上运行的kube-proxy作为守护进程将服务信息配置到iptables中来实现的（默认行为）。因此，在正常配置中，ClusterIP无法从集群外部接收通信。为了接收来自集群外部的通信，通常需要通过Service的type=LoadBalancer指定或配置基于Ingress资源的L7负载均衡器等设置。

Using DNS Pods and Services

与云提供商的L4负载均衡器进行协作(Service.Type=LoadBalancer)。

通过使用 Service 的 type=LoadBalancer 参数，可以将服务通过外部的 L4 负载均衡器进行公开。一旦进行了这个参数的设定，将会自动创建与云服务提供商（如 AWS、GCP 等）关联的负载均衡器。

请查看

Note: The given phrase “参考” in Chinese can have multiple meanings depending on the context. However, based on the provided context, the suitable translation would be “请查看.”

Services#type-loadbalancer

与L7负载均衡器的配合（入口）

Ingress是一种功能，用于将L7负载均衡器所需的设置信息表示为资源，接收来自集群外部（主要是互联网）的通信。

    internet
        |
   [ Ingress ]
   --|-----|--
   [ Services ]

Service.Type=LoadBalancer与其他的主要区别如下所示

ホスト名やパスによるルーティング、TLS終端が可能

Ingress自体はリソースとしてL7ロードバランサの情報をリソースとして表現するだけのもの

実際のロードバランサの設定はIngress ControllerというIngressリソースを監視する別の仕組みで行われる
これによりロードバランサの情報と具体的なロードバランサが分離される

在实施Ingress控制器方面，有以下几种选择。

HTTP Load Balancer (Google Container Engine)

参考一下

What is Ingress?

可插拔网络功能 (CNI)

Kubernetes的网络支持作为容器网络的通用接口的Container Network Interface（CNI）插件。存在着一些网络插件，例如Canal（Calico、Flannel）、Weave Net。

参考- 解释或引用以说明某个观点、论据或事实的行为。

Why Kubernetes doesn’t use libnetwork

网络策略的控制（NetworkPolicy）

NetworkPolicy 提供了按照 Namespace 进行网络设置和控制 Pod 访问的功能。如果 Kubernetes 的网络不支持 NetworkPolicy，则此设置将被忽略。

命名空间的网络设置示例的手册。

kind: Namespace
apiVersion: v1
metadata:
  # アノテーションで分離の設定をいれる
  annotations:
    # 全てのPod外からの通信を拒否する。1.5時点でのサポートはDefaultDenyだけ
    net.beta.kubernetes.io/network-policy: |
      {
        "ingress": {
          "isolation": "DefaultDeny"
        }
      }

网络策略的示例（Network Policy）

kind: NetworkPolicy
apiVersion: extensions/v1beta1
metadata:
  name: access-nginx
spec:
  # 制限する対象
  podSelector:
    matchLabels:
      run: nginx
  ingress:
    # 許可する対象
    - from:
      - podSelector:
          matchLabels:
            access: "true"

以下是参考：

1. 请提供中文的原生释义。

2. 请提供中文的本土阐述。

3. 请给出中文的本地化翻译。

4. 请提供中文的本地化版本。

5. 请给出中文的本土表述。

Network Policies

资源管理

Pod的资源控制（requests， limits）

通过指定spec.containers[].resources的requests和limits，可以控制Pod的资源（目前是CPU和内存）。requests是指定您希望最低限保证的值，而limits是指定可使用的最大值。

以下是一个手册示例。

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    # リソース制御の指定
    resources:
      # 最低限確保してほしいCPU、メモリ
      requests:
        memory: "64Mi"
        # 0.25コア分
        cpu: "250m"
      # 使用できる最大の値
      limits:
        # メモリの場合はこれを超えるとターミネートされる
        memory: "128Mi"
        cpu: "500m"
  # 以下省略

Resource Requests and Limits of Pod and Container

命名空间的资源控制（ResourceQuota）

资源配额提供了基于命名空间的资源控制机制。除了CPU和内存资源外，还可以根据每个命名空间设置对象数量（如Pod和Service的数量）。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    # リソース数の制限(ここではPod数)
    pods: "4"
    # 最低限確保してほしいCPU、メモリ
    requests.cpu: "1"
    requests.memory: 1Gi
    # 使用できるCPU、メモリの最大値
    limits.cpu: "2"
    limits.memory: 2Gi

您可以通过使用 `kubectl describe ns NAMESPACE` 命令来确认利用情况。

$ kubectl describe ns myspace
Name:   myspace
Labels: <none>
Status: Active

Resource Quotas
 Name:                  compute-resources
 Resource               Used    Hard
 --------               ---     ---
 limits.cpu             0       2
 limits.memory          0       2Gi
 pods                   0       4
 requests.cpu           0       1
 requests.memory        0       1Gi

No resource limits.

参考 – (reference / consult)

Understanding Resource Quotas

设置管理

保密管理 (Secret)

Secret是用于处理密码、私钥等机密信息的功能。使用Secret可以在应用程序定义中不包含机密信息。此外，Secret还用于ServiceAccount的凭证，以便应用程序可以访问API服务器，并且它会自动挂载为Volume。

Overview of Secrets

配置信息管理（ConfigMap）

ConfigMap是用于管理应用程序定义和配置信息的功能。配置信息可以通过环境变量、文件（Volume）、容器参数的形式传递给Pod。

KubernetesのConfigMapを試してみる

认证和授权

驗證

Kubernetes提供了各种用户认证方式，例如以下方式。Kubernetes本身不管理用户（除了ServiceAccount），而是根据不同的认证方法直接使用获取到的用户名。

方法備考X509 Client Certsクライアント証明書。CNがユーザ名、Oがグループになります。例: /CN=jbeda/O=app1/O=app2Static Token Fileトークン認証。CSVで定義します。Authorization: Bearer $TOKENヘッダで認証。Static Password FileBasic認証。CSVで定義します。Service Account TokensServiceAccountのJWT形式のトークン認証。OpenID Connect TokensOIDCのID Tokenによる認証。Webhook Token Authentication外部のWebAPIによる認証。Authenticating Proxy認証プロクシーを前段においてヘッダでユーザ名が渡される方式Keystone PasswordOpenstack Keystoneを使ったBasic認証。

考虑

Users in Kubernetes

同意

在Kubernetes中，提供了多种方式来进行认可。这是一种用于管理经过身份验证的用户能够执行哪些操作的功能。

方法備考AlwaysDeny全て否認。テスト用です。AlwaysAllow全て承認。AlwaysAllowの設定です。認可が不要な場合に使いますABACAttribute-Based Access Control。属性によるアクセス制御。Policyファイルによる静的な定義になるため、反映には再起動が必要ですRBACRoles-Based Access Contro。ロールによるアクセス制御。リソースを使った動的な管理が可能ですWebhook外部のWebAPIによる認可。

请看下列内容 for the Chinese translation.

Kubernetes: RBACの設定におけるAPIリソース

无头账户 (ServiceAccount)

在Kubernetes中，除了对人进行认证外，还提供了一种称为ServiceAccount的机制，用于无需人员介入（无头）情况下的应用程序认证。例如，在Kubernetes Dashboard与API服务器进行交互时，会使用ServiceAccount。

每个Namespace都会默认创建一个名为”default”的ServiceAccount，同时您也可以使用kubectl create serviceaccount创建自定义的ServiceAccount。

引用

Using the Default Service Account to access the API server

API服务器的请求控制（AdmissionControl）

Admission Control是Kubernetes API服务器中的请求控制功能。在对API请求进行认证和授权之后的阶段，它会单独决定是否接受该请求或进行控制。此外，在特定情况下，还可能对请求进行修改或执行其他操作。

在插件的形式下，提供了多种控制方式，可以通过API启动选项–admission-control来指定想要启用的选项，多个选项用逗号分隔。

在1.5版本中提供了以下插件。

ServiceAccount

参考：

Kubernetes: Admission Controlとは何か

安全

安全设置（SecurityContext）

SecurityContext（安全上下文）和PodSecurityContext（Pod安全上下文）允许对容器和Pod进行以下安全设置。

Pod的配置设置（PodSecurityContext）

seLinuxOptions SELinuxのオプション

runAsUser 実行するユーザのUID

runAsNonRoot rootで動かさないことを保証する (デフォルトfalse)

seLinuxContext SE Linuxのコンテキスト

supplementalGroups Supplemental Groupの指定

fsGroup ファイルシステムのGroupの指定

容器的设置（SecurityContext）

capabilities Linuxのcapabilitiesの設定

privileged 特権モードで動かすかどうか (デフォルトfalse)

seLinuxOptions SELinuxのオプション

runAsUser 実行するユーザのUID

runAsNonRoot rootで動かさないことを保証する (デフォルトfalse)

readOnlyRootFilesystem read-onlyのルートファイルシステムかどうか (デフォルトfalse)

请参阅

v1.PodSecurityContext

PodSecurityPolicy的强制实施

PodSecurityPolicy是一项能够对Pod强制执行安全策略的功能。通过在AdmissionControl中启用PodSecurityPolicy插件，您可以强制所有Pod遵守以下策略。

runAsUser 実行するユーザのUID

seLinuxContext SE Linuxのコンテキスト

supplementalGroups Supplemental Groupの指定

fsGroup ファイルシステムのGroupの指定

volumes 使えるボリュームの種別の制限

请给出以下参考的中文表述（只需一种）：

What is a Pod Security Policy?

镜像策略控制 (ImagePolicyWebhook)。

如果您希望在Kubernetes集群上自行控制容器镜像，ImagePolicyWebhook是一种可用的机制。下面列出了一些可能的使用情况。

署名されたイメージだけを動かしたい

图像策略webhook是一个机制，将包含在Pod中的容器映像信息传递给用户定义的WebAPI，并检查执行的可行性。容器映像控制本身需要使用自定义的WebAPI进行。Admission Controller插件被实现为ImagePolicyWebhook。

参考：

Kubernetes: Image Policy Webhookとは

与外部系统的交互

云服务商的支持 de

Kubernetes具备与云提供商（如AWS、GCP等）的负载均衡器和实例信息进行协作的功能。截至v1.5版本，以下云提供商的实现已经准备就绪。

vSphere

云服务提供商已定义了以下接口，并且每个提供商都根据此进行实现。支持情况因提供商而异。

// Interface is an abstract, pluggable interface for cloud providers.
type Interface interface {
    // LoadBalancer returns a balancer interface. Also returns true if the interface is supported, false otherwise.
    LoadBalancer() (LoadBalancer, bool)
    // Instances returns an instances interface. Also returns true if the interface is supported, false otherwise.
    Instances() (Instances, bool)
    // Zones returns a zones interface. Also returns true if the interface is supported, false otherwise.
    Zones() (Zones, bool)
    // Clusters returns a clusters interface.  Also returns true if the interface is supported, false otherwise.
    Clusters() (Clusters, bool)
    // Routes returns a routes interface along with whether the interface is supported.
    Routes() (Routes, bool)
    // ProviderName returns the cloud provider ID.
    ProviderName() string
    // ScrubDNS provides an opportunity for cloud-provider-specific code to process DNS settings for pods.
    ScrubDNS(nameservers, searches []string) (nsOut, srchOut []string)
}

https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider

永久存储连接（持久卷/持久卷声明）

PersistentVolume提供了与持久化存储集成的功能。在Kubernetes v1.5中，它支持以下存储。

vsphereVolume

请参考

Volumes

可扩展性 (kě

独自资源定义（ThirdPartyResource）

ThirdPartyResource是用户可以定义自己的Kubernetes资源的功能。它可以直接使用Kubernetes资源管理机制作为框架。例如，CoreOS的Operator和OpenID Connect Provider dex的数据存储等应用实例的应用越来越多。

关于ThirdPartyResource的详细信息，@shmurata的文章《Kubernetes作为一个框架》很好地总结了。

最后

对于 Kubernetes 功能的全面总结使我再次对其功能的丰富性感到惊讶。我将继续关注 Kubernetes 的发展。