kubernetes

Kubernetes 1.3の変更点(予定)

More than 1 year has passed since last update.

Kubernetes 1.3で入りそうな機能についてまとめてみました。現時点(2016/5/17)ではFeature Completeになっていなく、決定した情報ではないのでご注意ください。1.3のリリースは2016年6月末を予定しているようです。

主な参考情報

主な変更点

Ubernetes(複数クラスタ連携)の実装 (alpha)

Ubernetesは複数のKubernetesクラスタを連携させる機能です。("uber-"は"超える"の意味の接頭辞)。Ubernetesの利点は例えば以下のようなものがあります。

  • High Avaiability: AWS, GCPなどのクラウドプロバイダーやAvaiability Zoneをまたがってクラスタを連携させることで可用性が向上する
  • クラスタサイズの拡張: 現状クラスタのサイズの上限が1000〜2000ノードであるため、連携させることでそれ以上に拡張できる。

Phase1では構成的には以下のように、Ubernetes用のAPI Server、Scheduler、Cluster Controller、Service Controllerがクラスタの上位層として用意されるようです。(参考: Ubernetes Design Spec (phase one))。

image

すでにmasterブランチにはトップディレクトリにfederationという新しいディレクトリがマージされており、federated-apiserverというmainが追加されています。

Kubernetes 1.2の時点では、Ubernetes Liteと呼ばれる同一プロバイダの複数のAvailability Zoneだけをサポートするものが実装されています。(参考: kubernetes blog: Building highly available applications using Kubernetes new multi-zone clusters (a.k.a. "Ubernetes Lite"))

参考

PetSet(ステートフルアプリのサポート)の追加 (alpha)

PetSetは、ZooKeeperやetcdのように複数のインスタンスがそれぞれの状態を持って連携しあうような、ステートフルなアプリケーションをサポートするための仕組みです。初期から提案されている仕様らしく、元のIssueの連番は#260と若いです。

Pet という単語はおそらくPets vs. Cattleという話から来ており、ペットの様にそれぞれに名前を付けてユニークに扱う必要があるものを指します。逆にCattle(畜牛)はそれぞれを区別せず連番で呼ばれるようなものを指します。

ステートレスなアプリケーションは、それぞれのインスタンスを区別する必要がないCatlle的な扱いで良かったため、従来のReplication Controller(Replica Set)で単純に同一のPodを並べるだけで十分でした。しかし、それぞれのインスタンスごとに固有のデータを持つステートフルなアプリケーションは、それぞれをユニークに扱うPet的な扱いが必要ため、Replicaton Controllerで扱うのは難しい状況でした。そのためPetSetという機能が提案されました。

PetSetについてはドキュメント類がまだなので、マージされている/pkg/apis/apps/types.goのコメントが参考になります。

このコメントによれば、PetSetとはネットワークの識別子(DNSとホスト名)とストレージ(PersistentVolumeClaim)のマッピングを常に保証する仕組みのようです。

/pkg/apis/apps/types.go
// 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.localPod-a が削除されたとしても、新しく生成された Pod-d は同じストレージstorage-1 をマウントし、同じDNS名e1.etcd.default.svc.cluster.local でアクセスできるのでメンバーとして復帰できる、という仕組みだと理解しました。

DNS名 ストレージ Pod
e1.etcd.default.svc.cluster.local storage-1 Pod-a → Pod-d
e2.etcd.default.svc.cluster.local storage-2 Pod-b
e3.etcd.default.svc.cluster.local storage-3 Pod-c

KubernetesのIssue上ではarea/stateful-appsというラベルが振られていて、下記のようなアプリケーションがサポート予定の対象としてIssueが切られています。

  • ZooKeeper
  • etcd
  • Cassandra
  • Galera Cluster
  • Kafka
  • Vtess
  • ElasticSearch
  • Cockroach DB

参考

スケーラビリティ向上(2000ノード対応)

1.3でのゴールとしては2000ノードを目指すようです。

2000 nodes, 30 pods/node, 60K pods, 100 pods/node max, current latency

SIG-Scaleの資料 k8scale community update - 5/12 より

1.3の後は、クラスタのサイズの表現を変えて、200K cores/cluster, 10 pods/core, 100 pods/sec を目指すとしています。

以下は資料で挙げられていたパフォーマンスに関連するIssueです。

参考

rktnetes 1.0

rktnetesとはCoreOS社が開発するコンテナランタイムrktとKubernetesの組み合わせことです。1.3で正式版リリースを目指しているようです。CoreOS Fest 2016での発表時点(5/10)では、90%以上のE2Eテストが通るところまで来たと言っていました。

Dockerに対しての主な利点は以下が挙げられます。

  • Podをネイティブに扱える
    • DockerのようにPause container(Infra Container)を使ったトリッキーな仕組みが不要
  • コンテナを動かすのにdockerdのようなデーモンが不要
  • systemdとシームレスに統合できる

参考

Init Containers (alpha)

Pod内で初期化処理をするコンテナを指定をできる機能です。Podの定義にinitContainersという項目で、従来のcontainersで指定したコンテナの前に起動するコンテナを指定できるようになるようです。複数のコンテナを指定することができますが、containersがパラレルに起動されるのに対してinitContainersは指定した順番に1つずつ起動していくようです。

使用用途としては例えば以下のようなものが挙げられます。

  • データを動的にダウンロードしてくる
  • データベーススキーマの反映
  • アプリケーションが何らかの事前条件を満たすまでウェイトする
Proposalにあったyamlの例
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"]

参考

Scheduled Job (alpha)

Scheduled Jobはcronのようにスケジュールを指定したJobの指定ができるようになるものです。 (@koudaiii さんにコメントで教えてもらいました)。ConcurrencyPolicyという項目で多重起動の制御(Allow, Forbid, Replaceが設定できる模様)もできるようです。

Issueで挙げられていた例
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

参考

その他の変更点