CONTENTS
この記事をシェア：
はじめに
「DXを売る」シリーズを担当しているサイオステクノロジーの長谷川です。
前回は”APIマネージメント”を理解する！としてAPIマネージメントの必要性や製品について説明しました。今回は再度K8sの機能について知識を深めたい！と思い、 ”K8sの機能” について営業レベルで少し掘り下げたいと思います。
このBlogでは、DXソリューションを担当する営業の方を少しでも支援できるように分かりやすくご紹介します。参考にしてください。
第一回記事：「DXを売る」IT営業が気を付けるべき7つのポイント
第二回記事：「DXを売る」”DXに関心を持たせる” 営業トーク 」
第三回記事：「DXを売る」営業の”知ったかぶりコンテナ・トーク”」
第四回記事：「DXを売る」”IT自動化とDX推進を繋げる５つのポイント”
第五回記事：「DXを売る」営業の素朴な疑問 ”コンテナってどこでも動くの？”
第六回記事：「DXを売る」営業の素朴な疑問 ”サイドカーって何モノ？”
第七回記事：「DXを売る」営業の素朴な疑問 ”コンテナ向けOSって何？”
第八回記事：「DXを売る」DX営業”OpenShiftの特徴を説明できる?”（1/2）
第九回記事：「DXを売る」DX営業”OpenShiftの特徴を説明できる?”（2/2）
第10回記事：「DXを売る」DX営業 ”サービスメッシュ” を説明できる?
第11回記事：「DXを売る」DX営業 ”API連携とは何？”を理解する
第12回記事：「DXを売る」DX営業 ”APIマネージメントとは？” を理解する！
第13回記事：「DXを売る」DX営業 ”K8sの機能を理解する”！
第14回記事：「DXを売る」DX営業 ”Podmanを知っている？”
第15回記事：「DXを売る」DX営業 ”Pod”についての理解
【その１】K8sは何故必要か？
K8sの上に乗るコンテナですが、現在はDockerがディファクトで使われています。
実は、Dockerでも複数のDocker自体の管理や自動化をする機能（Docker Swarm）があるようですが、コンテナ間の設定や管理なので不便なことも多く、小規模のコンテナ管理以外はK8sを利用するのが一般的です。
ちょっと余談ですが、何故Dockerがディファクトとなったのか？ それには、Dockerの動作速度や移動のしやすさから選ばれているのだそうです。
さてK8sは、「コンテナオーケストレーション」であることはご承知のとおりです。
何故K8sを大規模でコンテナを使うときに必要なのでしょうか？ アホか！?と言われるかもしれませんが、コンテナ管理が面倒だからです。
以前のBlogにマイクロサービス型のアプリケーションについても簡単に説明したように、Cloud Nativeでは、マイクロサービスで機能ごとに小さくアプリケーションを作って、機能ごとの小さなアプリケーションを疎結合で繋げて複数機能の大きなアプリケーションのように見せています。
つまり、よほど単純でなければ一般的には多くのコンテナを使うことになるのです。
例えば運用しているとこんなケースは想定できます。
- コンテナのいくつかがダウンしたら？
- あるコンテナにトランザクション負荷がかかって、コンテナを負荷に応じて増やしたいとき？
- ノードがダウンして、ノード上のコンテナを別のノードに移したいとき？
- 他のシステムとの連携をしたいとき？
- ログを管理したいとき？
などなど、まだまだケースがあります
正直、手作業でDockerを監視して運用するほど非現実的なことはありません。
一人の管理者が1万コンテナ、2万コンテナの管理をするとしたら、私には出来る気がしません。
コンテナ＝子供 だとしたら、1,000人とか10,000人の子供の世話、管理を一人で出来ますか？
子供（コンテナ）同士が話すし、転ぶ子もいるし、泣く子もいる。あちこち違う方向に歩き出す子。
このような想像をすると、いかに管理や運用が大変なのかがわかると思います。
【その2】K8sの機能
この章では、KubernemesのWebページを私なりに理解して営業向けに解説をします。
- サービスディスカバリーと負荷分散
K8sは、DNSや独自のIPアドレスを使ってコンテナを公開し、コンテナにトラフィックが多くなるような負荷がかかると、同じコンテナのレプリカを負荷作って負荷分散をおこないます。これが一般にオートスケール機能といわれるものです。 - ストレージ オーケストレーション
K8sは、ローカルストレージやパブリッククラウドのストレージなどを選択したストレージシステムを自動でマウントすることができます。 - 自動化されたロールアウトとロールバック
「デプロイしたコンテナのあるべき状態を記述することができ、制御されたスピードで実際の状態をあるべき状態に変更することができます。」と説明されていますが、例えばコンテナによるサービスを新バージョンにしたい場合（ロールアウト）や古いバージョンに戻したい場合（ロールダウン）が出てきます。こういったデプロイを便利にしてくれる機能です。
新しいバージョンをリリースしたけど、問題があるから元のバージョンに戻そう！（ロールダウン）とか、新しいバージョンが出来たので、ロールアウト機能で新バージョンをリリースしよう！などが利用シーンとなります。 - 自動ビンパッキング
「コンテナ化されたタスクを実行するノードのクラスターをKubernetesへ提供します。各コンテナがどれくらいCPUやメモリー(RAM)を必要とするのかをKubernetesに宣言することができます。Kubernetesはコンテナをノードにあわせて調整することができ、リソースを最大限に活用してくれます。」と説明されています。
コンテナ毎にノードのサーバーのCPUやメモリーリソースを割り当てる必要があり、無駄に多くのリソースを割り当てると、コンテナの数によりクラウドの利用料金が多くかかってしまったり、コンテナがリソース不足でダウンしたりデプロイできなかったりします。
この機能により、コンテナに割り当てるリソースを自動化してくれます。
因みに、ビンパッキングという言葉はあまり耳にしないので、少し調べてみました。
Wikipediaでは、ビンパッキング問題という”離散数学の組合せ論の中のNP困難問題”とあり、なんだか難しそうです。与えられた荷物を詰める箱の最小数を見つけるものだそうです。
私なりにコンテナとCPUリソースを当てはめて想像すると、限られたCPUやメモリーに何個のコンテナを積むことが出来るのか？ ですかね？？
さらに、コンテナを配置するための考慮することは、メモリーやCPUだけではないようです。
ディスクI/O、コンテナ間の通信量、ディスクのスピード、CPUのクロック数など、コンテナ毎に設定するのはかなり大変なのだと思いますよね。
もっと便利なのは、リソースマネージメントをしてくれるので、あるノードのコンテナが100%となりこれ以上のコンテナを積めない場合、K8sは自動的に空いているノードに自動的にコンテナを移動してくれます。（Resouce Management）ユーザーは、どのノードに何のコンテナを配置するかは考えなくてよくなるわけです。 - 自己修復
「Kubernetesは、処理が失敗したコンテナを再起動し、コンテナを入れ替え、定義したヘルスチェックに応答しないコンテナを強制終了します。処理の準備ができるまでは、クライアントに通知しません。」の説明のとおりです。
コンテナは、揮発性である！ とかペットと家畜と以前のBlogで説明しました。たとえ家畜のように病気になっても死んでしまっても、再起動やダウンしたコンテナを新しいコンテナに入れ替えてくれます。
ノードのサーバーがダウンした場合も、自動で別のノードに復旧してくれます。（Auto Healing） - 機密情報と構成管理
「Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密の情報を保持し、管理することができます。機密情報をデプロイし、コンテナイメージを再作成することなくアプリケーションの構成情報を更新することができます。スタック構成の中で機密情報を晒してしまうこともありません」と説明されています。ここは補足しません。
【まとめ】
- 多くのコンテナを使う場合には、K8sを使わないと管理運用ができない
- 難しい言葉や単語は別にしても、オートスケール、リソースマネージメント、自己修復 程度は理解しておく
以上、今回は文字が多くてごめんなさい。m(_ _)m
今回のBlogの内容はお役に立ちましたでしょうか？
今後のBlog記事に関するご要望や実際のビジネスでのご相談事などございましたらお問合せいただきますようお願いいたします。最後まで読んでいただきありがとうございました。
