‫では､ なぜKubernetesが必要なのか､ その理由を説明しましょう｡
‫さて､ 復習の意味も込めて､ 以前のセクションを確認してみましょう｡
‫Swarmの最初のセクションで､
‫Swarm Mode Built-in Orchestrationというタイトルのレクチャーがあるんです｡
‫オーケストレーションが解決する問題や､ なぜオーケストレーションが必要なのかについての基礎知識は､
‫これで十分でしょう｡ 最初は､ アプリケーションをデプロイするためにどんなオーケストレーションのメリットがあるのか､
‫そもそもオーケストレーションが必要なのかどうかを理解することが間違いなく重要であることを強調しておきます｡
‫オーケストレーションは確かに人気を集めていますが､ コンテナを実行する唯一の方法というわけではありません｡
‫Docker runの利用については､ こちらでご紹介しています｡
‫Docker Composeについてお話しました｡
‫他のプラットフォームの提供やサービスについてもお話しました｡
‫今でもオーケストレーションなしでAWSのシングルノードでコンテナを動かしているお客さんがいます｡
‫そのプラットフォームの機能を使って､
‫オーケストレーションと同じような抽象化を行い､ 自動スケーリンググループやElastic Load Balancingなど､ 私たちが10年以上アプリケーションのデプロイメントを管理するために使ってきたものを利用することができます｡
‫彼らは洗練されたシステムを持っているので､ それをすべてオーケストレーションに変えてもあまりメリットがないと考えているのです｡
‫さて､ 私たちのほとんどは最終的に何らかの形でコンテナ・オーケストレーションを使うことになるでしょう｡
‫なぜなら､ それがこの業界の進む道だと思うからです｡
‫私がオーケストレーションを使うかどうかの判断基準としているのは､
‫特定の環境に必要なサーバーの台数と､
‫アプリケーションや環境そのものの変化率で､ この2つの掛け算がオーケストレーションの利点になります｡
‫つまり､ オーケストレーションは､ 変化を自動化し､
‫物事の状態を監視して､ すべてが期待通りの状態であることを確認するために設計されているのです｡
‫例えば､ 健康な状態で動作しているアプリなど｡
‫また､ アプリケーションを頻繁に変更しない場合､ 例えば月に1回程度しか変更しないのであれば､ オーケストレーションやその導入､
‫管理､ セキュリティに関わる労力は必要ないでしょう｡
‫特に､
‫ソロの開発者やごく小さなチームであればなおさらです｡
‫そこで､ Elastic BeanstalkやHerokuのようなアプリケーション・デプロイ・プラットフォームが､
‫独自のオーケストレーションに代わる選択肢として注目され始めているのです｡
‫もちろん､ オーケストレーションが必要だとわかった人から受ける最も多い質問は､
‫どれがいいのか､ ということです｡
‫本当に2019年の現時点では､ 少なくとも2つか3つの主要なプラットフォームが存在します｡
‫クラウドソリューションも含めると､ そこには4つか5つの主要なプラットフォームがあるかもしれません｡
‫このコースでお話ししているのは､ どこでも通用する上位2つです｡
‫それがSwarmとKubernetesです｡
‫また､ AWSにしかないECSや､ Cloud
‫Foundry､ MesosやMarathonなど､
‫もう少し前からある伝統的な製品など､ クラウドプラットフォームに特化したものもあります｡
‫しかし､ オンプレミスやクラウド､ あるいはマルチクラウドでのコンテナ運用を考えているのであれば､
‫ECSのようなクラウドに特化したサービスは､ Kubernetesが登場する以前からあったものなので､ あまりお勧めできないかもしれませんね｡
‫しかし､ AWSに特化していて､ コンテナをデプロイするのがその場所だけという場合は､
‫この方法を使うことができます｡
‫私のお客様や生徒さんの多くは､ 「ハイブリッドなものが欲しい」と考えています｡
‫自分のデータセンターでも､ マルチクラウドでも運用できるという意味です｡
‫一カ所だけで動くということはありえない｡
‫その結果､ SwarmやKubernetesが大きな選択肢となるわけですが､
‫この2つは最も人気のあるコンテナオーケストレーターです｡
‫あらゆるクラウド､ データセンター､ そしてIoTのような小規模な環境でも動作する可能性があります｡
‫オーケストレーターとしてKubernetesを選んだ場合､
‫次に大きな決断となるのが､ どのディストリビューションを使うかです｡
‫そのためにはまず､ クラウドのマネージド・ソリューションを利用するのか､
‫それともベンダーの製品を自分でサーバーにインストールして独自のソリューションを展開するのかを見極める必要があります｡
‫Docker Enterpriseや､ Red HatのRancher
‫OpenShiftなど､ ベンダーがサポートする一般的なディストリビューションは､
‫これまでにもお話したとおりです｡
‫Ubuntuを手がけるCanonicalは､
‫自社版を持っています｡
‫VMwareは独自のバージョンを持っています｡
‫PKSも同様です｡
‫実は今､ Kubernetesのインフラやソフトウェア会社のベンダーソリューションは､
‫ちょっと圧倒されるくらいたくさんあるんです｡
‫Kubernetesの認定ディストリビューション一覧へのリンクをリソースで紹介しておきますね｡
‫KubernetesからのAPIが直接使われること､ そしてそれが完全にサポートされていることが保証されているので､
‫これらのいずれかを使用したいと思います｡
‫つまり､ ワークロードとインフラを設計するYAMLファイルを､
‫あるKubernetesベンダーから別のベンダーに移行しても､ ほとんどのことがそのまま使えるというのが理想的です｡
‫ここでもうひとつ､ Kubernetesの生のGitHubアップストリームバージョンを使うという選択肢を紹介します｡
‫それが､ すべての分配金のベースになっているのです｡
‫例えば､ アップストリームを見ると､ Kubernetes
‫1. 14 リリース｡
‫そうすると､ ベンダーの製品を見るときに､ どのKubernetesのバージョンに対応しているのかが気になりますよね｡
‫通常､ ベンダー製品は数バージョン遅れているものですが､
‫今はどこもなるべく最新にしておくという競争になっています｡
‫だから､ ほとんどの場合､ 1バージョンだけ古いものを見ることが多いですね｡
‫さて､ ベンダーソリューションで得られるものは､
‫そのベンダーのサポートオプションの他に､ 他のツールもバンドルされていることです｡
‫KubernetesがSwarmと少し違うのは､
‫すぐに使えるようにするためには､ いろいろなものを追加する必要があることです｡
‫ですから､
‫ベンダーが提供するソリューションには､ カスタム認証ソリューション､
‫カスタムWeb管理､ カスタムネットワークなど､ さまざまなものが含まれます｡
‫私は一般的に､ あなたの要件を何も知らずに､
‫おそらくGitHubのKubernetesの純粋な上流バージョンは必要ないだろうと勧めます｡
‫Kubernetesのレポをクローンして､ それだけを実行する必要はないのです｡
‫今は､ 学習用として最適です｡
‫実際､ Kubernetesを学ぶ方法として､ そこから始めることをおすすめしています｡
‫しかし､
‫ベンダーのソリューションになると､ セキュリティやネットワークなど､
‫それぞれ少しずつ異なってきます｡
‫だから､ 片方を覚えて､ もう片方も同じように動作すると思い込むのは難しいでしょう｡
‫しかし､ 本番の話を始めると､ 管理がしやすくなるため､ まずはそういったベンダーのソリューションを使ってみようとなると思います｡
‫サポートのオプションが充実する
‫一般的に､ 物事はすぐに良く､ 速く動くようになります｡