これまでKubernetesについてスタディしてきた事を利用価値の観点から12項目にまとめました。思入れによって私見が混じっている部分もあるかもしれませんが根拠のリンクを添えています。 今後、Kubernetesは本当に素晴らしい次世代のIT基盤に成長していくと思います、
ビジネス面での利点
理由1 頻繁なアプリケーションのリリースを可能にする実行基盤
アプリケーションの自動的なロールアウトとロールバックは、Deploymentsによって、頻繁な新機能リリースや、緊急のバグ修正版入れ替えなどデリケートな作業を自動化して、安全かつ円滑に実行できます。
- アプリケーションの本番提供中に、新機能提供や不具合修正などの改定版のコンテナを無停止で切り替える機能を提供する。
- 切替え中のパフォーマンス的な悪影響やアプリケーションの不具合に伴うサービス停止を回避するため、コンテナ入れ替えの戦略を設定できる。
- アプリケーションが不安定な動作をした場合、ロールアウトを自動停止し、オペレーターの介入で元へ戻すロールバックができる。
理由2 止められないサービスに適した高可用性な基盤
セルフ・ヒーリング(自主回復)を実現する Replication Controllerによって、止まらないサービスを構築できます。
- 密接に連携するコンテナのセットをまとめてポッドと呼ばれる単位を構成して、内部プロキシにより負荷分散する水平分散クラスタを構成する。
- 予めリクエスト量に対応できるポッドの複製数を設定するが、ノードの障害によりポッドの稼働数が減った場合、自動的に必要なポッド数を起動して能力を維持する。
- 能力維持のために、新たに起動したポッドは、内部プロキシに自動登録され、リクエストが割り振られる様になる。
理由3 ビジネスの状況に合わせて伸縮自在な基盤
ポッドの水平オートスケーリング Horizontal Pod Autoscalingによって、ビジネスの規模に即した適切な規模に調整ができ、売上に貢献し無駄なコストを圧縮できます。
- ポッドのCPU稼働率の閾値を超える場合、並列分散クラスタを構成するポッド数を自動的に増やす事で、処理能力を向上させる事ができる。
- クライアントからのリクエスト数が減り、CPU稼働率が下がった場合、ポッド数を自動的に減少させ、処理能力を調整する事ができる。
- ポッド数の増加に伴う、ポッドへのIPアドレスの自動付与、ノードへのポッドのデプロイなど人手を介さず自動実行できる。
運用的での利点
理由4 仮想サーバーやベアメタルとハイブリッド構成可能な柔軟な運用基盤
コンテナで実行に向かないアプリケーションは、そのまま従来のベアメタルや仮想サーバーに残しておきたい場合、そして、アプリケーションのモダナイズ途上の遷移状態では、Headless services や Publishing services - service typesによって、Kubernetesと既存環境のハイブリッドなシステムを構成できます。
- データベースの高速なI/O処理、GPGPUを利用した機械学習などベアメタルを利用したい場合、k8sクラスタ外のサービスディスカバリー機能を提供する
- オンプレミスのサーバーやクラウドの仮想サーバーとk8sクラスタのポッドと連携するため、外部サーバーを抽象化するサービスを設定できる。
- k8sクラスタ上で動作するマイクロサービスをオンプレミスやクラウドの仮想サーバーから呼び出すためのパブリッシュ・サービスを提供する。
理由5 コンテナで開発したアプリの本番運用に適する運用基盤
アプリケーションの開発とテストが完了して登録したコンテナのリポジトリのアドレスとイメージ名を指定して、Kubernetesクラスタへデプロイする事ができます。 開発環境から本番環境へ切り替えるための接続先情報は、すべて、k8sクラスタ環境に設定されているため、アプリケーションを一切変更する事なく、コンテナをそのまま本番環境で開始する事ができます。
理由6 オンプレとクラウドの両方で利用できる運用基盤
Kubernetesを稼働させるためのソフトウェア製品とサポートするハードウェア製品、そして、メガクラウドのベンダーでKubernetesサービスが提供されており、特定の場所にロックインされません。
オンプレミスでKubernetesをサポートする製品
- HPE Bright Cluster Manager
- HPE コンテナー向け永続ストレージ
- IBM Cloud Private
- VMware エンタープライズ クラスのKubernetes導入を実現するPivotal Container Service(PKS)
- Red Hat OpenShift
- Red Hat Kubernetes によるコンテナのオーケストレーション
- Ubuntu on Kubernetes
パブリック・クラウドのKubernetesサービス
- Amazon Elastic Container Service for Kubernetes (Amazon EKS)
- Microsoft Azure Container Service
- Google Cloud Platform Kubernetes Engine
- IBM Cloud Container Service
- Alibaba Cloud Container Service(中国語)
理由7 オーケストレーションが可能な運用基盤
Kubernetesは、YAMLファイルの設定で、ロードバランサー、水平分散クラスタリング、ストレージの管理、内部のサービス・ディスカバリーやドメイン登録を実施でき、運用生産性を大幅に改善できます。
- サービス・ディスカバリーとロードバランシングのサービス Services
- パスワードを隠蔽した設定共有 Secrets
- 環境別の構成情報 Using ConfigMap
- スケーラブルなバッチジョブ管理 Jobs
- ストレージの管理 Persistent Volumes
技術的での利点
理由8 特定企業に支配されない標準技術
Kubernetesは、もともとGoogleのプロジェクトでしたが、CNCFへ寄贈されオープンソースとしてプロジェクトが運営され、特定の企業に依存しない技術として開発が進められています。
- Kubernetes Production-Grade Container Orchestration
- Kubernetesがコンテナ時代のソフトウェア産業を全面的に支配、大企業もCloud Native Computing Foundationに参集する
- Wikipedia Kubernetes
理由9 軽量高効率なコンテナ技術
Kubernetesのベースとなっているコンテナ技術は、ハードウェアをエミュレーションする仮想マシンよりも、はるかに軽量で高速に起動します。 アプリケーションが依存するOS、ミドルウェア、開発言語のライブラリなど必要なソフトウェアのスタックをコンテナとしてパッケージ化するために、ポータビリティに優れた実行イメージです。 開発環境と本番環境の差を最小に留める事が可能となり、アプリケーションの開発と運用の生産性改善に大きく寄与します。
理由10 活発な開発が継続
業界の主要な企業、すなわち、メガクラウド各社、ソフトウェアやハードのメーカが参加して開発が活発に続けられています。
コスト的な利点
理由11 マルチ・クラウドへのパスとして利用
CNCFが実施する「Kubernetes適合認証プログラム」によって認定されたk8s基盤を利用する事で、他社k8s環境との互換性が保証されます。 これにより、複数のk8s環境を併用できる様になり、特定一社への依存しなくなる事から、事業継続性やコスト競争力を高める事ができます。
理由12 高密度なサーバー利用によりムダの排除
Kubernetesはコンテナをベースとした技術であるため、特定のハードウェアやソフトウェアの構成にロックインされません。 コンテナのセットであるポッドは、異なるサーバー上でもk8sクラスタ内であれば疎通が保証され負荷分散の対象となります。そして、再配置に伴う作業は煩わしい作業はk8sが処理し、移行時の性能維持のためのストラテジーによりポッド数を制御するため、本番稼働中に再配置を実施できます。このため無駄の無い高効率なインフラ運用が可能となります。
- 自動的にビンパック問題を解決する
Managing Compute Resources
以上