Kubernetesが気になって眠られない
普段触る技術がレガシーで全く相見えないワードでしたが、最近外部の勉強会やSE友達と話す機会があって
Kubernetes（略称はk8s)というワードをよく見聞きします。
読み方はクーベネティス/クーベルネイテス。スペル的にクーバネティスって読みたいんだけど、そんな発音してたら笑われるのかな・・こわいこわい。
単語自体知っていないと「？？？」となる響きですね。（実際なります。体験済みです笑）
Kubernetes（k8s）とは
困ったときは公式を見るのが一番です。Kubernetesによると・・・
Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications.
一言で言うと、Kubernetesとはコンテナ化されたアプリケーションのデプロイ、スケーリングと管理を自動で行うためのオープンソースシステムです。
k8sはコンテナ化されたワークロードとサービスを管理するための移植可能かつ拡張可能なオープンソースプラットフォームです。宣言的な設定（Declaretive Configuration)と自動化を用意にします。大規模でかつ急成長するエコシステムを有しています。k8sのサービス、サポートやツールは広く使われています。
続いて、What is Kubernetes?では以下の６つ観点でk8sが説明されていますので同様の観点で書いていきます。
- Why do I need Kubernetes and what can it do?
- How is Kubernetes a platform?
- What Kubernetes is not
- Why containers?
- What does Kubernetes mean? K8s?
- What’s next
なぜKubernetesが必要なの？何ができるの？
Kubernetesにはいくつかの特徴があります。
- コンテナプラットフォーム
- マイクロサービスプラットフォーム
- ポータブルクラウドプラットフォーム などなど
クーベネティスはコンテナ中心的な管理環境を提供します。演算やネットワーク、ストレージインフラをユーザの代わりに管理します。IaaSを柔軟にPaaSをとても単純にするとともに、インフラプロバイダ間の移植を可能にします。
Kubernetesはどのようなプラットフォームなの？
Kubernetesは多くの機能を提供していますが、新機能の恩恵を受けるシナリオが常にあります。アプリケーション固有のワークフローが合理化され、開発速度が加速することでしょう。許容できるアドホックオーケストレーションは、当初しばしば堅牢なスケールの自動化を要します。こうした理由から、デプロイやスケール、管理を簡単にするためのコンポーネントとツールのエコシステムを構築するためのプラットフォームとして機能するようにクーベネティスは設計されたのです。
Labelesを利用すことでリソースを整理でき、Annotationsを利用することで、カスタム情報でリソースを装飾してワークフローを容易にするし、管理ツールがチェックポイントの状態に簡単に移行できるようになります。
加えてKubernetes control planeは開発者とユーザが利用できる同じAPIの上に構築されています。ユーザは、汎用的な command line toolの対象とすることができるAPIを使って、スケジューラといった自身のコントローラ作成することができます。
このデザインによってクーベネティスの上に数多くのシステムを構築することが可能になりました。
Kubernetesはこういうものではないよ
クーベネティスは古くからある全包括的なPaaSシステムではありません。ハードウェアレベルではなくコンテナレベルで動作するので、スケーラビリティ、負荷分散、ロギング、モニタリングといったPaaSが提供する一般的に適用可能な共通機能をいくつか提供します。しかしクーベネティスは画一的なものではなく、先に述べた規定のソリューションは任意で選択可能なものなのです。開発者のプラットフォームを構築するためのビルディングブロックを提供しますが、一方でユーザの選択肢と柔軟性は保たれています。
クーベネティスとは
- サポートするアプリケーションの種類を制限しません。 ステートレス、ステートフル、データプロッシングを含む極めて多様な種類のワークロードをサポートすることを目指しています。あるアプリケーションがコンテナの中で動くなら、クーベネティス上でも良く動くとでしょう。
- ソースコードをデプロイしたり、アプリケーションをビルドしたりしません。CI/CDワークロードは技術的要件だけでなく、嗜好や組織風土によって決定されます。
- ビルドインサービスとしてアプリケーションレベルのサービスは提供しません。例えば、ミドルウェア、データプロッシングフレームワーク、データベース、キャッシュ、クラスタストレージシステムなどです。このようなコンポーネントはクーベネティスで動きます。そして、（また、）Open Service Brokerといったポータブルメカニズムを通して、クーベネティス上で稼働しているアプリケーションからアクセスすることができます。
- ロギング、モニタリング、アラートのソリューションを指定しません。概念を証明するものとしてのいくつかのインテグレーションとエクスポートメトリクスを集めるためのメカニズムを提供しています。
- 構成言語・システムを提供したり委任することはしませんそれは宣言的な仕様からなる任意の形式に対象とされる宣言的なAPIを提供しています。
- 包括的なマシン構成、メンテナンス、マネジメント、自己修復システムを提供したり採用したりしません。
加えて、クーベネティスはただのオーケストレーションシステムではありません。実際、オーケストレーションの必要性を排除しています。オーケストレーションの技術的定義は定義されたワークフローの実行だけです。（まずAを実行し、次にB、そしてCを実行する・・など） 対照的に、あるべき状態に向かって現在の状態を継続的に駆動する、独立した構成可能な制御プロセスのセットで構成されます。AからCにどのように到達するかは重要ではありません。中央集約的な制御も必要ありません。これにより、より使いやすく、より強力、より堅牢、より可用性のある、より拡張可能なシステムが実現しています。
なんでコンテナなの？
（出典：https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/）
アプリケーションをデプロイする古い方法はOSパッケージマネージャを使用しているホスト上にアプリケーションをインストールすることでした。アプリケーションの実行可能ファイル、構成、ライブラリ、互いとホストOSとのライフサイクルが絡み合うという欠点がありました。予測可能なロールアウト、ロールバックを可能とするための恒久的なVMイメージを作ることはできましたが、VMはとても重く移植性もありません。
新しい方法はハードウェアの仮想化ではなくOSレベルの仮想化に基づいたコンテナをデプロイすることです。これらのコンテナは互いに、またホストとも分離しています。つまりコンテナは独自にファイルシステムを持っているし、互いのプロセスを見ることはできないし、計算資源の使用を制限することができます。VMより構築が簡単です。というのもインフラやホストのファイルシステムから分離されていて、クラウドやOSディストリビューション間をまたいで移植可能であるからです。
さいごに
公式ページをガシガシ読んでみましたけど、英語力のなさが文章ににじみ出てしまった・・・
大枠つかんだらとりあえず実際はどういうところで使われているのか、実際に活用されている場面や構成とかを調べてみたり、機会があれば触ってみていろいろできるもっと理解が深まると思っているので年内にはチャレンジしてみようかと思います！
それでは！
