連載:第五回「DXを売る」営業の素朴な疑問 ”コンテナってどこでも動くの?”

ビジネス

はじめに
「DXを売る」シリーズを担当しているサイオステクノロジーの長谷川です。
コンテナは、どこでも動くの? という疑問がありませんか?
私も同様に疑問に思っていたので弊社のエンジニアに質問して私なりに纏めてみました。お役に立てば嬉しいです。

このBlogでは、DXソリューションを担当する営業の方を少しでも支援できるように分かりやすくご紹介します。参考にしてください。
第一回記事:「DXを売る」IT営業が気を付けるべき7つのポイント
第二回記事:「DXを売る」”DXに関心を持たせる” 営業トーク 」
第三回記事:「DXを売る」営業の”知ったかぶりコンテナ・トーク”」
第四回記事:「DXを売る」”IT自動化とDX推進を繋げる5つのポイント”

【疑問1】コンテナ化したアプリケーションは、生K8s、OpenShift、Rancher、Tanzuどこでも検証無しに動くの?

回答はYes。コンテナが動くエンジン(docker)が共通ならば、コンテナプラットフォームの差異に関わらず動きます。

しかし条件があります。それはOSの差です。Linux同士であればLinuxカーネルがどのLinuxディストリビューションでも共通なので大丈夫です。しかし、Linux以外のOS(例えばMicrosoft WindowsなどはLinuxカーネルとの互換性がないので、コンテナのOSとして選択はできても互換性がないのでコンテナとしての相互可搬性はありません。
今後は、Linuxの知識がますます必要になりますね。
(Linuxディストリビューションとは、例えばRed Hat, Ubuntu, CentOS, Debianなどです)

【疑問2】K8sのcontrol node(Master)をクラスター化?

K8sの構成をざっくり言うと、アプリケーションを動かすためのworker nodeとそれらを管理するcontrol nodeがあります。(OpenShiftでも同じです)

この疑問はcontrol nodeのHAについてです。何故control nodeをクラスターにしてHA構成にしなくてはならないのか?
control nodeが死んでしまうとworker nodeが全部死んでしまうからです。

で、control nodeのHAは、3台構成が最低構成のようです。
3台の次は5台というように奇数で構成されるようです。(へー、通常のサーバーのHAとは少し違うようですね)

もう少し調べてみると、クラスターになっているcontrol nodeには3つのステータスがあるようです。大まかにはLeader役とFollower役があるようで、Leaderが基本的に処理します(Leaderは一人)。さらにFollowerには、次期Leaderとなるcandidate役がいて(なんとこのcandidate役は立候補制らしいのですが、candidate役がLeaderになるには、クラスター内の多くの支持がないとLeaderにはなれないのだそうです)
これらの目的は、HAの実現のために、複数のノードで構成される分散サービスの一貫性保証のためです。(ちょっと難しいので頭の片隅に置いておきましょう)

【疑問3】マルチクラウドにおけるcontrol nodeは、各クラウド毎に必要?

リージョンが異なる環境としてマルチクラウドでK8sを利用する場合、それぞれのリージョンでcontrol nodeを持つ必要があるのでしょうか? それともどこか1か所にcontrol nodeを設置すればよいのでしょうか?

営業さん向けの内容なので実用面を考慮した説明にします。ご提案の際にはそれぞれのクラウドでcontrol nodeが必要です。
これには、障害対応のためにも各クラウドにcontrole nodeが必要のようです。
他の理由もあるかもしれませんが、私の知識不足です。

【まとめ】

  1. コンテナ化されたアプリケーションはLinux OS上のコンテナプラットフォーム(K8s、OpenShift、Tanzu、他)であればどこでも動く
  2. Control node(Master)は3台が基本で、奇数で増やす
  3. マルチクラウド、ハイブリッドクラウドでは、各クラウドにcontrol node(Master)が必要

以上、
今回のBlogの内容はお役に立ちましたでしょうか?
今後のBlog記事に関するご要望や実際のビジネスでのご相談事などございましたらお問合せいただきますようお願いいたします。最後まで読んでいただきありがとうございました。