Kubernetes がなぜ人気があるのでしょうか?

この記事の公開時点で、Kubernetes は登場して約 6 年が経過しており、過去 2 年間で人気が高まり、最も人気のあるプラットフォームの 1 つになりました。今年は3番目に人気のあるプラットフォームになりました。 Kubernetes について聞いたことがない方のために説明すると、Kubernetes はコンテナ ワークロードを実行およびオーケストレーションできるプラットフォームです。

コンテナは、2007 年の cgroups、2002 年の名前空間など、Linux カーネル プロセス分離構造として始まりました。2008 年に LXC が導入されて以来、コンテナの重要性は増し、Google は Borg と呼ばれる独自の内部「すべてをコンテナ内で実行する」メカニズムを開発しました。 2013 年に Docker がリリースされ、コンテナに革命が起こりました。当時、コンテナをオーケストレーションするための主なツールは Mesos でしたが、広く採用されていませんでした。 Kubernetes は 2015 年にリリースされ、すぐにコンテナ オーケストレーションの事実上の標準になりました。

Kubernetes の人気を理解するために、いくつかの質問について考えてみましょう。開発者が本番アプリケーションの展開方法について最後に合意したのはいつですか?ツールをそのままの状態で実行できる開発者を何人知っていますか?現在、アプリケーションの仕組みを理解していないクラウド運用エンジニアはどれくらいいるでしょうか?この記事ではその答えを探ります。

YAMLとしてのインフラストラクチャ

Puppet と Chef の世界から見ると、Kubernetes にとっての大きな変化は、コードとしてのインフラストラクチャから YAML としてのインフラストラクチャへの移行です。 Pod、構成、デプロイメント、データ ボリュームなど、Kubernetes 内のすべてのリソースは、YAML ファイルで簡単に表現できます。例えば：

 APIバージョン: v1
種類: ポッド
メタデータ:
名前: サイト
ラベル:
アプリ: ウェブ
仕様:
コンテナ:
 -名前: フロントエンド 
  画像: nginx
  ポート:
    - コンテナポート: 80

この表現により、DevOps や SRE は、Python、Ruby、JavaScript などのプログラミング言語でコードを記述することなく、ワークロードをより簡単に、より完全に表現できるようになります。

インフラストラクチャをデータとして活用するその他の利点は次のとおりです。

GitOps または Git Operations バージョン コントロール。この方法では、すべての Kubernetes YAML ファイルを Git リポジトリに保存できるため、変更がいつ行われたか、誰が変更したか、何が変更されたかを正確に把握できます。これにより、組織全体の透明性が高まり、メンバーが必要なものを探すためにどこに行く必要があるかについての曖昧さがなくなり、効率が向上します。同時に、プル リクエストをマージするだけで、Kubernetes リソースに自動的に変更を加えることが簡単になります。

スケーラビリティ。リソースを YAML として定義すると、クラスター オペレーターは Kubernetes リソース内の 1 つまたは 2 つの数値を変更してスケーリング動作を変更することが非常に簡単になります。 Kubernetes には、トラフィックが少ないときと多いときの両方を処理できるように、特定のデプロイメントに必要なポッドの最小数と最大数を決定するのに役立つ、水平ポッド自動スケーリング コントローラーがあります。たとえば、トラフィックの急増により、より多くの容量が必要になる可能性があるデプロイメントを実行している場合は、maxReplicas を 10 から 20 に増やすことができます。

 apiバージョン: autoscaling/v2beta2
種類: Horizo​​ntalPodAutoscaler
メタデータ:
名前: myapp
名前空間:デフォルト 
仕様:
スケールターゲット参照:
 APIバージョン: アプリ/v1
種類: デプロイメント
名前: myapp-deployment
最小レプリカ数: 1
最大レプリカ数: 20
メトリクス:
 - タイプ: リソース
リソース：
名前: CPU
  ターゲット：
    タイプ: 利用
    平均使用率: 50

セキュリティと制御。 YAML は、Kubernetes に何がどのようにデプロイされているかを確認するのに最適な方法です。たとえば、セキュリティの観点から、ワークロードが非ルート ユーザーとして実行されているかどうかが主な懸念事項の 1 つです。 YAML/JSON バリデーターの conftest や、ポリシー バリデーターの Open Policy Agent などのツールを活用して、ワークロードの SecurityContext でコンテナが root として実行できることを確認できます。これを行うには、ユーザーは次のような単純な OPA rego ポリシー式を使用できます。

パッケージメイン
 
拒否[メッセージ] {
 input.kind = "デプロイメント"  
 input.spec.template.spec.securityContext.runAsNonRoot = true ではない 
 msg = "コンテナはルートとして実行しないでください"  
 }

クラウド プロバイダーの統合。テクノロジー業界における大きなトレンドの 1 つは、パブリック クラウド プロバイダーでワークロードを実行することです。 Kubernetes では、クラウド プロバイダー コンポーネントの助けを借りて、各クラスターが、そのクラスターが実行されているクラウド プロバイダーと統合できるようになります。たとえば、AWS の Kubernetes でアプリケーションを実行し、サービスを通じてアプリケーションにアクセスできるようにする場合、クラウドプロバイダーは LoadBalancer サービスを自動的に作成し、Amazon Elastic Load Balancer を自動的に構成してトラフィックをアプリケーション Pod に転送するのに役立ちます。

拡張機能

Kubernetes はスケーラビリティが非常に高く、開発者に好評です。既存のリソースには、Pod、Deployment、StatefulSet、Secret、ConfigMap などが含まれます。ただし、ユーザーと開発者は、カスタム リソース定義の形式でさらにリソースを追加できます。たとえば、CronTab リソースを定義する場合は、次のようにします。

 apiバージョン: apiextensions.k8s.io/v1
種類: カスタムリソース定義
メタデータ:
名前: crontabs.my.org
仕様:
グループ: my.org
バージョン:
 -名前: v1
  提供:本当 
  ストレージ: true  
スキーマ:
    オープンAPIV3スキーマ:
      タイプ: オブジェクト
      プロパティ:
        仕様:
          タイプ: オブジェクト
          プロパティ:
            cronスペック:
              タイプ: 文字列
              パターン: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'  
            レプリカ:
              タイプ:整数 
              最小: 1
              最大: 10
スコープ: 名前空間
名前:
複数形: crontabs
単数形: crontab
種類: CronTab
短縮名:
 -ct

次に、同様の方法で CronTab リソースを作成します。

 APIバージョン: "my.org/v1"  
種類: CronTab
メタデータ:
名前: my-cron-object
仕様:
 cronSpec: "* * * * */5"  
画像: my-cron-image
レプリカ: 5

Kubernetes の拡張性のもう 1 つの形態は、開発者が独自の Operator を作成できるようにすることです。Operator は、Kubernetes クラスターで実行され、制御ループ パターンに従う特殊なプロセスです。オペレーターを使用すると、ユーザーは Kubernetes API と通信して CRD (カスタム リソース定義) を自動的に管理できます。

コミュニティには、開発者が独自のオペレーターを作成できるツールがいくつかあります。これらのツールの 1 つは、Operator Framework とその Operator SDK です。 SDK は、開発者がオペレーターの作成をすぐに開始するためのフレームワークを提供します。たとえば、次のようなコマンドラインを使用して開始できます。

 $ operator-sdk 新しい my-operator --repo github.com/myuser/my-operator  

これにより、YAML ファイルと Golang コードを含む Operator のテンプレート全体が作成されます。

 。
 |____cmd
 | |____マネージャー
| | |____メイン
|____go.mod
 |____デプロイ
| |____ロール.yaml
 | |____ロールバインディング.yaml
 | |____サービスアカウント.yaml
 | |____演算子.yaml
 |____ツール.go
 |____行く.合計 
 |____.gitignore
 |____バージョン
| |____バージョン.go
 |____ビルド
| |____ビン
| | |____ユーザー設定
| | |____エントリポイント
| |____Dockerファイル
|____パッケージ
| |____アピス
| | |____apis.go
 | |____コントローラー
| | |____コントローラ

次に、次のように API とコントローラーを追加できます。

 $ オペレータ SDK にAPIを追加--api-version=myapp.com/v1alpha1 --kind=MyAppService    
 $ オペレーターSDKコントローラーを追加--api-version=myapp.com/v1alpha1 --kind=MyAppService  

最後に、Operator イメージをビルドしてコンテナ レジストリにプッシュします。

 $ operator-sdk ビルド your.container.registry/youruser/myapp-operator

開発者がさらに制御する必要がある場合は、Golang ファイル内のテンプレート コードを変更できます。たとえば、コントローラーの特定の詳細を変更するには、controller.go ファイルを変更できます。

別のプロジェクトである KUDO を使用すると、宣言型 YAML ファイルのみを使用してオペレーターを作成できます。たとえば、Apache Kafka Operator は次のように定義され、ユーザーはわずか数個のコマンドで Kubernetes 上に Kafka クラスターをインストールできるようになります。

 $ kubectl kudo で Zookeeper をインストールします
$ kubectl kudo kafka をインストールします

別のコマンドを使用して調整することもできます。

 $ kubectl kudo kafka をインストール--instance=my-kafka-name \  
        -p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181 \
        -p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m \
        -p BROKER_COUNT=5 -p BROKER_MEM=4096m \
        -p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3 \
        -p ネットワークスレッド数 = 10 -p IO スレッド数 = 20

革新

過去数年間、Kubernetes は 3 ～ 4 か月ごとにメジャー バージョンがリリースされており、毎年 3 ～ 4 つのメジャー バージョンがリリースされていることになります。前回のリリースでは 30 を超える追加機能と変更があったことからもわかるように、展開される新機能の数は減っていません。さらに、Kubernetes プロジェクトの GitHub アクティビティが示すように、このような困難な時期であっても、貢献は減速する兆候を見せていません。

新しい機能により、クラスター オペレーターはさまざまなワークロードを実行する際の柔軟性が向上します。ソフトウェア エンジニアは、より多くの制御権を持ち、アプリケーションを直接本番環境にデプロイできることも好みます。

コミュニティ

Kubernetes の人気のもう一つの大きな側面は、その強力なコミュニティです。まず、Kubernetes が 2015 年にバージョン 1.0 をリリースしたとき、それはベンダー中立の組織である Cloud Native Computing Foundation に寄贈されました。

プロジェクトが進むにつれて、Kubernetes のさまざまな領域をターゲットにした多数のコミュニティ SIG (Special Interest Groups) も登場し、常に新しい機能を追加して、Kubernetes をよりユーザーフレンドリーなものにしています。

Cloud Native Foundation は、現時点では世界最大のオープンソース イベントである CloudNativeCon/KubeCon も主催しています。通常、年に最大 3 回開催されるこのイベントには、Kubernetes とそのエコシステムを改善し、3 か月ごとにリリースされる新機能の一部を活用したいと考えている何千人もの技術専門家やプロフェッショナルが集まります。

さらに、Cloud Native Foundation には技術監視委員会があり、SIG と連携してクラウド ネイティブ エコシステムにおける Foundation の新規および既存のプロジェクトを検討しています。ほとんどのプロジェクトは Kubernetes の価値提案に貢献しています。

最後に、コミュニティが互いにサポートし合い、新しい参加者を歓迎するという意識的な努力がなければ、Kubernetes がこれほどの成功を収めることはなかったと私は信じています。

未来

将来、開発者が直面する主な課題の 1 つは、コードが実行されるインフラストラクチャではなく、コードの詳細に重点を置く方法です。このため、サーバーレスは、この課題に対処するための主要なアーキテクチャパラダイムの 1 つとして浮上しています。 Knative や OpenFaas など、Kubernetes を使用して開発者からインフラストラクチャを抽象化する非常に高度なフレームワークがすでにいくつか存在します。

この記事では Kubernetes について簡単に紹介しましたが、これは氷山の一角にすぎません。ユーザーが活用できるリソース、機能、構成は他にもたくさんあります。今後も新しいオープンソース プロジェクトやテクノロジーによって Kubernetes が強化され、進化していくでしょう。前述したように、貢献とコミュニティが大きな役割を果たします。