この文書は、kubernetesユーザーズガイドの「Kubernetes Overview」の和訳（参照した原文は release-1.0版）で、一部意訳や不正確な部分が含まれているかもしれません。kubernetesは Apache License v2.0で提供されています。
Kuebernetesは、コンテナ化したアプリケーションを１つのクラスターとして複数ホストにまたがって管理するためのオープンソースシステムである。Kubernetesはコンテナ化されマイクロサービスにもとづくアプリケーションを簡単でパワフルにデプロイすることを意図している。
Kubernetesはアプリケーションのデプロイ、スケジューリング、アップデート、メンテナンス、スケールのためのメカニズムを提供する。Kubernetesの主要機能は、クラスタの状態がユーザーの意図に継続的に沿うことを保証するためコンテナを積極的に管理することにある。運用するユーザーがマイクロサービスを立ち上げられるようになっているようにすべきであり、スケジューラーは適切な場所を見つけられるようにできる。また、ユーザーがカナリア・デプロイメントのようなパターンに沿ってアプリケーションをリリースしていけるようようツールとエクスペリエンスを改善したいと考えている。
Kubernetesは Dockerと Rocketというコンテナをサポートしており、他のコンテナイメージ形式やコンテナランタイムも将来的にサポートする。
現状はKubernetesは継続動作するステートレスな（例：Webサーバーやインメモリのオブジェクトキャッシュ）ものと”クラウド・ネイティブ”のステートフルアプリケーション（例：NoSQLデータストア）にフォーカスしているものの、近い将来には本番のクラスタ環境で知られる他のあらゆる種類のワークロードをサポートする。たとえば、バッチやストリーム処理、トラディショナルなデータベースなどがある。
Kubernetesでは、すべてのコンテナは pod内で動作する。podは単一コンテナや協調動作する複数のコンテナ群をホストできる。後者のケースでは、pod内のコンテナ群は同一のマシーンに配備されることが保証されていて、リソースを共有できる。podは0個以上の volumeを含むことができる。これは単一コンテナのみ利用することも、pod内のコンテナ間で共有することも選べるディレクトリである。ユーザーが作成する各podのために、システムは健常で十分な処理能力を利用できるマシーンを探索し、そこで対応するコンテナを起動する。コンテナが異常終了した場合、Kubeletという名のKubernetesのnodeエージェントによって自動で再起動される。しかし、podやそのマシーンが異常終了した場合では、ユーザーが replication controllerを定義しない限り、自動で移動して再起動することはない。これは次で説明する。
ユーザーはpodじたいを作成したり管理することも可能だが、Kubernetesを使うことでユーザーは2つの一般的なpod関連の運用を移譲してシステム管理を劇的に簡素化できる。1つは単一のpod設定にもとづいて複数のpodレプリカをデプロイすること、もうひとつはpodやマシーンが異常終了した際に代替podを作成することである。この挙動を管理するKubernetes APIオブジェクトは replication controllerと呼ばれる。podをテンプレートで定義することで、システムがいくつかの数（ユーザーが指定する）のpodをインスタンス化できるようにしている。複製されたpod群のセットは、アプリケーション全体を構成する場合もあるし、1マイクロサービスであったり、多層アプリケーションの1レイヤとなる場合もある。ひとたびpod群が生成されたら、システムはpodと動作しているマシーンが健常かを継続的に監視しつづける。もしpodがソフトウェアの問題やマシーンの故障で異常終了した場合には、replication controllerは正常動作するマシーン上で新たなpodを自動作成し、pod群のセットが求められる複製レベルを守れるよう維持する。同一または異種のアプリケーションの複数のpod間で単一のマシーンを共有できる。もしユーザーがpodやマシーンの異常終了時に再作成したいのであれば、複製しないシングル構成のpodであってもreplication controllerは必要となることに注意すること。
しばしばpod群をひとまとめに参照できた方が便利なことがある。たとえばオペレーションの変更を実施したり、ステータスを問い合わせる際にpod群を限定したい場合などがある。一般的なメカニズムとして、ユーザーはほとんどのKubernetes APIオブジェクトに対して labelと呼ばれる任意のkey-valueのペアを付けられ、labelセレクタ（labelに対するkey-valueの問い合わせ）を用いてAPI操作の対象を選定できる。各リソースはこのオブジェクトに対して外部ツールから任意のメタデータを保存・取得できるkeyとvalueの文字列マップも持っていて、これは annotationと呼ばれる。
Kubernetesは独自の ネットワークモデルをサポートしている。Kubernetesはフラットなアドレス空間を推奨していて、ポートは動的に割り当てないこととし、ユーザーにとって都合の良いどのようなポートでも選べるようにしている。これを実現するために、各podにIPアドレスを割り当てている。
今どきのインターネットアプリケーションはマイクロサービスをレイヤ状に重ねて構成することが一般に見られるようになっている。たとえば、一連のWebフロントエンドが分散構成のインメモリkey-valueストアと通信し、さらにそれが複製されたストレージサービスと通信している。このようなアーキテクチャの基礎を提供するため、Kubernetesは serviceという抽象化機能を用意していて、マイクロサービスを構成する動的なpod群に対応する安定的なIPアドレスと DNS名を使えるようにしている。このセットはlabelセレクタを用いて定義するため、どのようなpod群の組み合わせでも参照できる。Kubernetesのpod内のコンテナがこのアドレスに接続したとき、この接続は元のマシーン上で動作するローカルのエージェント（kube proxyと呼ばれる）によって適切なバックエンドのコンテナ群の１つへと転送される。具体的なバックエンドは負荷分散のためラウンドロビン・ポリシーで選定される。kube proxyがpodが新規ホスト上の新しいpodに置き換えられた場合にもバックエンドの動的なセットの追跡を引き受けることで、serviceのIPアドレス（とDNS名）が決して変わらないようになっている。
Kubernetes内のすべてのリソース、たとえばpodなど、はURIで識別され、UIDを持っている。URIの重要な要素はオブジェクトの種類（例：pod）やオブジェクト名、そしてオブジェクトの namespaceである。何らかのオブジェクトの種類をとったとき、すべての名前はnamespace内でユニークになっている。namespaceなしでオブジェクト名が提供されるような状況では、default namespaceであると仮定される。UIDは時間と空間を問わずユニークになっている。
Chuma Takahiro
関連記事
