计划中的Kubernetes 1.3的更改点

1 年 ago
雅, 悟
3 minutes

我整理了一下可能包含在Kubernetes 1.3中的功能。请注意，截至目前（2016/5/17），它还没有完全实现，所以这只是一种猜测。1.3版本预计在2016年6月底发布。

重要的参考信息

    • kubernetes/kubernetes v1.3 milestone

 

    • Kubernetes Community Hangout Working Doc

 

    • Kubernetes 1.3 – Effort tracking dashboard

 

    • Youtubeの Kubernetes Community Meeting の録画

 

    Kubernetes Wiki Release 1.3

以下是主要的修改内容

Ubernetes（多集群協調）的實現（alpha版本）

Ubernetes 是一个可以协调多个 Kubernetes 集群的功能。（”uber-” 是表示「超越」的前缀）。Ubernetes 的优点包括以下几点。

High Avaiability: AWS, GCPなどのクラウドプロバイダーやAvaiability Zoneをまたがってクラスタを連携させることで可用性が向上する

クラスタサイズの拡張: 現状クラスタのサイズの上限が1000〜2000ノードであるため、連携させることでそれ以上に拡張できる。

在第一阶段中，构造性地准备了Ubernetes的API服务器、调度器、集群控制器和服务控制器作为集群的上层组件。（参考：Ubernetes设计规范（第一阶段））。

image

目前，主分支（master branch）已经合并了一个名为federation的新目录，其中添加了一个名为federated-apiserver的main文件。

在Kubernetes 1.2时，实现了只支持同一提供商的多个可用区的功能，被称为Ubernetes Lite。（参考：Kubernetes博客：使用新的多区集群（又名“Ubernetes Lite”）构建高可用应用程序）

请参考

Ubernetes: task list #23653

Ubernetesの実装状況がまとまっています

SIG Federation
Ubernetes Working Group – meeting notes
Kubernetes Cluster Federation (a.k.a. “Ubernetes”)

Ubernetes Design Spec (phase one)

添加PetSet（对有状态应用程序的支持）（alpha版）。

PetSet是一种机制，用于支持类似ZooKeeper或etcd的多个实例相互协调各自状态的有状态应用程序。它似乎是从一开始就被提议的规范，并且原始问题的编号是#260，属于较新的问题。

“Pet”这个词可能来自于”宠物与牲畜 (Pets vs. Cattle)”的讨论，指的是需要给每个个体取一个独特的名字并独自对待的像宠物一样的东西。相反，“Cattle”（畜牛）指的是不区分个体，按顺序标号的东西。

无状态的应用程序不需要区分每个实例，因此在以 Cattle 为基础的传统复制控制器（副本集）中，只需简单地将相同的 Pod 放置在一起就足够了。然而，对于具有每个实例独有数据的有状态应用程序，需要像宠物般对待每个实例，因此在复制控制器中处理它们变得困难。因此，提出了 PetSet 功能。

关于 PetSet，由于还没有相关文档，可以参考/pkg/apis/apps/types.go中合并的注释。

根据这个评论，PetSet似乎是一种始终保证网络标识符（DNS和主机名）与存储（持久卷索取）之间映射的机制。

// PetSet represents a set of pods with consistent identities.
// Identities are defined as:
//  - Network: A single stable DNS and hostname.
//  - Storage: As many VolumeClaims as requested.
// The PetSet guarantees that a given network identity will always
// map to the same storage identity. PetSet is currently in alpha and
// and subject to change without notice.

我只是根据评论中的想象，以下内容可能存在错误。

假设我们定义了如下表格形式的映射规则，例如在 etcd 的情况下。即使 e1.etcd.default.svc.cluster.local 的 Pod-a 被删除，新生成的 Pod-d 仍然可以挂载相同的存储 storage-1，并可以通过相同的 DNS 名称 e1.etcd.default.svc.cluster.local 进行访问，以此作为成员重新加入，我理解是这种机制。

DNS名ストレージPode1.etcd.default.svc.cluster.localstorage-1Pod-a → Pod-de2.etcd.default.svc.cluster.localstorage-2Pod-be3.etcd.default.svc.cluster.localstorage-3Pod-c

Kubernetes的问题上被标记为”area/stateful-apps”标签，并且已经为以下应用程序创建了问题作为计划支持的目标。

    • ZooKeeper

 

    • etcd

 

    • Cassandra

 

    • Galera Cluster

 

    • Kafka

 

    • Vtess

 

    • ElasticSearch

 

    Cockroach DB

请参考

    • PetSet (was nominal services) #260

 

    • Apigroup and alpha resource for petset #24315

 

    Petset controller #24912

提高可扩展性（支持2000个节点）

目标是在1.3时达到2000个节点。

每个节点有2000个节点，每个节点有30个Pod，总共有60K个Pod，每个节点最多有100个Pod，目前的延迟。

在1.3版本之后，我们计划改变集群规模的表达方式，目标是每个集群拥有200K个核心，每个核心有10个容器，每秒生成100个容器。

以下是与表演相关的问题，在资料中提到。

epic: Reducing network overhead and optimizing kubernetes control plane communications #23709

ネットワークのオーバーヘッド低減とKubernetes APIサーバーへの通信の最適化

Enable http2 on client connections. #25280

通信をHTTP/2を使うようにする

Upgrade to etcd v3 plan #22448

etcd v3へのアップグレード

Proposal for introducing Protobuf serialization #22600

protocol buffersのサポート

Split the “resync interval” on reflectors into “relist interval” and “resync interval” #23394

请参考

    • K8scale weekly agenda

 

    k8scale community update – 5/12

可替代的中文表达：
rktnetes 1.0版本

rktnetes是CoreOS公司开发的将容器运行时rkt和Kubernetes结合起来的解决方案。目前正在致力于推出1.3正式版。据CoreOS Fest 2016大会（5/10）的发布时称，已经实现了超过90%的端到端测试通过。

以下是对Docker的主要优点：

    • Podをネイティブに扱える

DockerのようにPause container(Infra Container)を使ったトリッキーな仕組みが不要

コンテナを動かすのにdockerdのようなデーモンが不要
systemdとシームレスに統合できる

请参考

    • rktnetees-v1.0 milestone

 

    KubeCon EU 2016: “rktnetes”: what’s new with container runtimes and Kubernetes

初始容器（alpha版）

在Pod中，可以指定在初始化过程中执行的容器。在Pod的定义中使用initContainers字段，可以在常规的containers字段中指定的容器之前启动指定的容器。可以指定多个容器，但是与containers字段并行启动不同的是，initContainers会按照指定的顺序逐个启动。

可以举例如下的用途。

    • データを動的にダウンロードしてくる

 

    • データベーススキーマの反映

 

    アプリケーションが何らかの事前条件を満たすまでウェイトする
pod:
  spec:
    initContainers:
    - name: wait
      image: centos:centos7
      command: ["/bin/sh", "-c", "for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; exit 1"]
    containers:
    - name: run
      image: application-image
      command: ["/my_application_that_depends_on_myservice"]

参考：

    • Proposal for implementing init containers #23666

 

    Add init containers to pods #23567

预定工作（Alpha版）

Scheduled Job是一种类似于cron的可以指定任务计划的功能。据@koudaiii提供的评论，还可以通过ConcurrencyPolicy选项来控制多重启动（可以设置为允许、禁止、替换）。

apiVersion: batch/v2alpha1
kind: ScheduledJob
metadata:
  name: pi
spec:
  schedule: "0 0 0 0 0"
  startingDeadlineSeconds: 30
  concurrencyPolicy: "Allow" 
  suspend: false
  jobTemplate:
    spec: 
      template:
        spec:
          containers:
          - name: pi
            image: perl
            command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
            restartPolicy: Never

请您参考一下

    ScheduledJob ControllerのProposal

其他的更改点 de

NVIDIA GPU support #24836

NodeのGPUをcpu, memoryなどと同じようなリソースとして扱えるようにするもの

Automatically create the kube-system namespace #25196

kube-systemネームスペースが自動的に作られるようになった。地味に嬉しい

Upstream Openshift Authz #23396

Openshiftの認可の仕組みを取り入れる

Implement OIDC client AuthProvider #25270

OpenID ConnectのRefresh Tokenの実装され、Refresh Tokens #18549の問題が解決

kubectl create secret tls #20176

ingressにtlsのサポートが入ったので、証明書のシークレットをkubectlで作れるようにするもの

✖
广告
将在 10 秒后关闭
bannerAds