helloworlds

not a noun, it's a verb

【k8s】kubernetes 入門 - #01

kubernetes 入門記事。

この記事からタイトル"kubernetes 入門"という記事は、

以下の技術書を元にk8sの理解度を上げるために書いていこうと思います。

※ 初版が2018年と古いですが、他の書籍と比べ、基本要素についてk8s開発者が端的に説明しているので、実践的なコマンドやデプロイ方法などより、要素の役割に焦点を置いて、私の理解含め記事にしようと思います。

kubernetes とは?

そもそもkubernetesが何かというお話です。

kubernetesは、kubeやk8sなどと略して呼ばれることが多々ありますね。

(以下k8sと記載することがあります)

kubernetesとは、一言でいうと、オーケストレータです。

オーケストレータと言われても、オーケストラ?ってかんじですねw

もう少しいうと、コンテナ化されたアプリケーションをデプロイするためのもの。

分散システムが当たり前となり、そのシステムを構築し、デプロイ・メンテを行うタスクが多々あると。

そのタスクをシンプルに行えるのがk8sということになるでしょうか。

全くk8sに触れたことがない方は、"どうやらDockerの仲間らしい" とか "Dockerを簡単に扱えるようにしたもの" みたいなイメージがあるのではないでしょうか。

Docker を使用し、アプリケーション開発をしたことがある人であれば、開発において難儀に思う部分が想像できるかと思います。

今の段階では、k8sとは、コンテナ化されたアプリをデプロイする便利なものくらいにイメージしておけばOKでしょう。

もう少し詳しく

元はといえばk8sGoogleが開発し、 そして2014年にOSS(オープンソース)化されたようです。

現在では様々な人にサポートされ、色々な分野で導入されているようです。

Kubernetesの名称は、ギリシャ語に由来しており、操舵手などの意味があるそうです。 (なので、アイコンは船の舵なのですね!)

過去から今を考える

従来は物理サーバー上で以下のようにアプリが実行されていました。

この場合、1つのアプリケーションがリソースを多く消費してしまうと、

他のアプリケーションはパフォーマンスが下がり正常に実行されなかったりしてしまうでしょう。

なので、1つの物理サーバーに1つのアプリケーションを実行させることが安全策になるでしょう。

しかし、あるアプリでは特定の時間帯のみ実行されることを想定していたり、

そもそも物理サーバーを多く所有することは運用の負荷にもなりますし、コスト面を考慮してもあまり効率的ではないことが想像できます。

そして、仮想化が主流になりました。

CPU上で複数のVMを実行させることができるので、アプリケーション間の制御(セキュリティレベル)も可能となりました。

Hypervisorは仮想マシン(VM)を作成することができるので、

1つのサーバーに異なるOSを置き、その上でアプリを実行することができます。

なので、VMを1つのセットとして考えると、

上記の物理サーバーの頃と比べて運用やコスト面で優位に扱えることがわかります。

(まあ、要件によっては運用コストが高くなったよ!とか障害時の・・・とか、HypervisorとてKVMやら何やらあるので、AWSのEC2ではどうとかこうとかあるのですが、ここでは細かいことは割愛!w)

ここにきてようやく、コンテナの話です。

仮想化の方との主な違いは、コンテナはオペレーションシステム(HostOS:kernel)を共有することができる点です。

Docker を例とするとイメージしやすいかもしれません。

VMと同じようにコンテナでも各自のファイルシステムやCPUの共有、メモリー、プロセス空間等を持っています。

VMではハードウェアのリソースを分割し、仮想環境を分離していますが、

コンテナではカーネルを共有し、アプリレベルでの分離をしています。

このため、高速な起動やリソースの有効活用がより行えるということになります。

ということは、コンテナの方が良いじゃん!!といことになりかねませんが、

メリットばかりでもないというのが現場では感じられるでしょう。

例えば、

VMではそのままのセキュリティ対策を流用できることも少なくはないはずです。

方法は違えど、物理マシンと同様な考え方で構成などを行っていくことができますし、ノウハウも多いはずです。

一方コンテナでは、ネットワークなど扱いがVMとは異なることも多く、

現場レベルでは運用しているアプリケーションを、コンテナ化できるか考慮することが必要となり、 大規模なアプリになればなるほど、移行に掛かる時間はもうなんとやらです・・w

サービス(アプリ)に負荷が掛かれば、オートスケールしなければなりませんし、

コンテナは楽に作成できたとしても、運用されるコンテナが増えるにつれ、 管理をしないといけない数が増え、運用コストも負荷が掛かることになります。

コンテナということは、Dockerイメージなる、イメージを適切に管理しなければなりませんし、

実際に開発している開発者が、開発に集中できるように適切な方法で管理しなければ、

さらに運用にさくコストは増え続けてしまうことになります。

長くなったけど

ここまで、今までのアプリケーションのデプロイ方法までの道筋と言いますか、

アプリが稼働している環境について大雑把に振り返ってみましたが、k8sの話がまだですねw

まあ、つまり、このコンテナ型の運用につきk8sが活躍してくるといった具合です!!

本来もう少し技術書の沿った内容をこの記事で記載しようと思いましたが、

長くなってしまったので、今回はここまでにします。

次回は1章から気になった・重要な・詳しく理解していきたい点について記載しようと思います。

過去のDockerに関する記事はコチラ↓