kubernetesをWebエンジニアが学ぶ意義について

一般的に、開発ディベロッパーはインフラに関する知識が浅い場合が多く、Dockerですらvirtualboxなどの開発環境構築の代替えとしての活用しかしていない場合が多いです。

Dockerを始めとしたコンテナ技術は、Production環境でこそ真価を発揮します。

その代表格として「私の環境では動いている...」というディベロッパーにとって最も悩ましいことの一つである環境問題を限りなくゼロにすることが出来る点が挙げられます。

Dockerコンテナを使用した開発及び本番環境運用においては、その両者のなかにインフラ環境の差異が発生しません。

このことにより、開発環境で動作確認が取れている機能の本番環境での正常稼働率をかなり高い確率で維持できます。このことは、余計な心配事を減らすことでディベロッパーのクリエイティビティの低下を低減することに寄与するでしょう。

また、k8sを始めとしたコンテナオーケストレーションの技術を身につけることで、マイクロサービスアーキテクチャーが何たるかを理解することができるでしょう。

昨今のプログラミング言語は、その言語によって得意な事、不得意な事の特色が明確になってきており、より良いサービスを一つのバックエンド言語で完成させることはほぼ不可能です。

これら多種多様な開発言語で作られた個々のサービスを互いに連携させ、一つの大きなアプリケーションとして稼働させることが、現代のプロダクト開発においては重要になってきます。

これらの連携の部分をimperative(命令的)ではなく、declarative(宣言的)な指示により自動化する仕組みをk8sを通じて学ぶ事で、ディベロッパーは本来の仕事である開発だけにより注力できるようになるでしょう。

Kubernetesとは何か

Kubernetesは、宣言的な構成管理と自動化を推進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースプラットフォームです。(by 公式)

Kubernetesはギリシャ語で航海長とかパイロットって意味。

簡単に言うとDockerなどのコンテナをうまく管理するツールです。

コレなしでは複数ホスト上でコンテナ管理するのは煩雑。

開発とリリースを高速でまわす現代の開発現場においてポータビリティの高いコンテナを複数ホストでオーケストレーション。する技術は欠かせない。

docker run と docker-composeの違いは同一ホスト上での複数コンテナ管理が出来るかどうかでした。

ただこの弱点は、いくら複数コンテナがあったとしても唯一のホストが壊れたらコンテナも消滅してしまいます。

じゃあ、ホストを大量生産して複数コンテナを複数ホストに振り分けようというのがContainer Orchestration!!

その結果、単一障害点を軽減できるし、そもそもホスト間でのロードバランシグ、モニタリング、コンテナ同士のネットワーキングなど、自力でやってたら死ねますよね？

それらを宣言的なオーダーだけで自動的に行ってくれるのがkubernetesなのです。

Dockerは単一ホスト内の複数コンテナ同士はやり取りできるが、複数マシン上で外側とのやりとりにNATが必要。

だからDockerはホスト間の連携が煩雑になるため容易にスケールアウトできない。

一方、k8sは複数台ホストの管理、統合をするためのシステムで、構成される実行環境をあたかも一台の実行環境のように扱える。

要するに、沢山のマシンを一個の大きなマシンとして使えるってこと。

pod(コンテナ)が一つだけ起動しているとトラフィックの増加でコンテナがパンクする。

複数のPodで冗長化することで高トラフィックにも耐えうる。

また、仮にPodがいくつか死んでも、死活監視し自動修復してくれます。

さらに、無停止更新で新機能をシームレスに提供できる。

ほかにも、稼働中にアプリをスケールする水平の自動スケーリング（CPU稼働率の閾値でコンテナ数を増減）

複数ホスト上の複数コンテナへのロードバランシング/ワークロードの分散（Service,L4ロードバランサー）などをしてくれます。

冒頭でもk8sを学ぶ意義について述べましたが、k8sでの運用の利点は、従来、優秀なインフラエンジニアがやっていた仕事を宣言的な命令書を作成するだけで自動的に行ってくれる点です。

次回からはそれらの中身について掘り下げて行こうと思います。