やさしくわかる「Kubernetes基礎」
前回エントリで、"やさしくわかる「Docker基礎」"という社内勉強会セミナーの参加ブログを書きましたが、社内外から好評だったので、
今回はCloud Nativeサービス勉強会シリーズの第二回である「Kubernetes基礎」について書いてみたいと思います！
★社内勉強会ですが、非公開情報は一切ないということで、講師陣の方にはブログを書くことを事前に許可を得ています！
やさしくわかる「Docker基礎」やCloud Nativeサービス勉強会シリーズ、なぜ私が参加しているのか等については、前回のエントリをご覧ください。
今回の講師は、Hayakawa Hiroshi（@hhiroshell）さんです。セミナー企画はRyusaburo Tanaka（@rewtheblow）さんです。@rewtheblowさんの写真も撮ったので、以下にのせてみます。
それでは、どうぞ！
「Kubernetes基礎」の内容
全体１時間のアジェンダは以下。
- イントロダクション
- コンテナ・オーケストレーションとは
- Kubernetesの基礎
- Oracleが提供するマネージドKubernetes
です！
１．イントロダクション
ペースレイヤーに基づく考え方
従来、ITシステムに求められることと言えば、会社の規模が大きくなるにつれて会計や人事などバックオフィス業務を効率化させたり、バックオフィスでなくとも既存業務をいかに円滑に推進させていくか、ということだったかと思います。
しかし、近年では、そもそもITが牽引して新しいビジネスを発見していこうとする動きも顕著になってきました。
その中で、ガードナーにより「ペースレイヤーモデル」という考え方が提唱されました。これは、業務アプリケーションをユーザーの使用状況と変更頻度（ペース）で分類し、異なるガバナンスにて管理しようということです。
モバイルの場合は、数週間という頻度で改修されることも多く、高頻度でリリース可能な方法が求められてきました。
高頻度リリースのための開発方法とは
高頻度リリースの方法として、ここでは２つ紹介されていました。
マイクロサービス・アーキテクチャでは、大規模システムを作る際に小さいアプリの組み合わせにすることによって、各アプリの機能追加をしやすくし、サービス単位での変更を可能としているため、高頻度リリースに適しています。
継続的インテグレーション/デリバリーでは、なるべく人手を介さず、ソースコードの管理や変更を自動化することによって、デプロイ本番までのリリース期間を短縮し、人為的なミスも減らし手戻りを少なくするという効果があります。
つまり、これらの方法のように、従来から高頻度リリースに適した方法は存在していたのです。
コンテナが注目を浴びる理由
前述の通り、高頻度リリースに向いた開発方法は従来から存在していましたが、コンテナはそれらを実現するために良い実現手段であったということになります。見ていきましょう。（※コンテナ自体の説明は前回エントリをご確認ください）
マイクロサービス・アーキテクチャの観点
コンテナの独立性
コンテナでは、小容量で低オーバーヘッドな仮想環境が実現できるため、小さいアプリの組み合わせであるマイクロサービス・アーキテクチャを支える手段として適しているといえます。
コンテナの高集約性
マイクロサービス・アーキテクチャのアプリは小さいだけでなく、多数ということも特徴のひとつです。そのため、多数のアプリを可動させることのできるコンテナとは相性が良いのです。
継続的インテグレーション/デリバリーの観点
コンテナの可搬性
アプリの実行環境をコンテナとしてパッケージ化し使いまわすことで、論理的に同じだが規模が違う環境や、同じ環境を異なるステージに作成することなどが容易になります。
コンテナの新たな課題
コンテナによって高頻度リリースの開発手法は問題なく支えられていくはず、、、でしたが、活用され始めると新たな課題が出現してきました。それは、コンテナの数が大量になってきた、ということです。以下は一例ですが、さまざまなオペレーションを管理・実行する対象がどうにも増えてきてしまった、、ということです。
２．コンテナ・オーケストレーションとは
コンテナ・オーケストレーター
これらの課題を解決する方法として、複数のコンテナのデプロイ、スケーリング等を自動管理するプラットフォームとしてコンテナ・オーケストレーターが登場してきました。自動管理とは、自動で複数のマシンに分散配置してくれたり、コンテナが落ちたら自動で新たに立ち上げたりしてくれるということです。聞いただけで、便利そうですね。数あるコンテナ・オーケストレーターの中でデファクトとなりつつあるのがKubernetesということです。次からは、他のコンテナ・オーケストレーターとKubernetesの違いに焦点を当てて、特徴を述べてきます。
Kubernetesの優位性①：機能拡張の柔軟性
コンテナ運用の効率化をするために、監視・ログ収集・ネットワークトラフィックの監視など、他のOSSと組み合わせることで機能を強化することができます（左）
また、たとえば機械学習のプラットフォームとして用いたい場合、実際の運用では作成したモデルをどうアプリに反映させるのか等まで考えなければなりませんが、そのような機能もOSSとの組み合わせで、機能を拡張することができます（右）
このような使い方は特殊ではないため、OSSとして使い方を開発していくためのエコシシステムもKubernetesに出来上がっていることも、特徴のひとつです。
Kubernetesの優位性②：利用方法の幅広い選択肢
Kubernetesは、主要なベンダーからマネージドサービスが提供されておりハードル低く使い始めることもできるし、フルスクラッチでも可能です。特殊要件がある場合はOSSをカスタマイズすることもできますし、一方でシンプルに運用管理を楽にしたり、お試しで使ってみたい場合には、マネージドサービスを利用することもできます。
Kubernetes優位性③：他のクラウドサービスとの統合
②にて、ベンダーがマネージドサービスを提供されていることとも関係しますが、クラウドベンダーがKubernetesのマネージドサービスを提供しているため、Oracleが提供するDatabaseやGoogleが提供するAPIなど、別のサービスとも組み合わせて利用しやすいことも特徴としてあります。
３．Kubernetesの基礎
Kubernetesの全体像
３つの構成要素があるということです。
- Kubernetesクラスター
- Kubectl
- コンテナレジストリ
Kubernetesクラスター
コンテナ領域の本体で、実際のワークロードが可動する場所、とのこと。
Kubectl
クラスターに対して指示するためのコマンドラインツール、とのこと。
コンテナレジストリ
Kubernetesで動かしたいコンテナイメージを保存するためのもので、Kubernetes専用のものではなく、Docker単体で利用する場合と同じものが利用されるということ。
Kubernetes上でコンテナが動作する様子
ここらへんから私には厳しい領域になってきていますが、、元気があるうちに一気にいきましょう！！
Pod
複数のコンテナを束ねる単位で、コンテナをデプロイする場合の最小単位ということ。イメージとしては、コンテナの入れ物。
Container
アプリケーションのワークロードの実態。
Deployment
データ。Podの状態の情報を持っている。
Deployment Controller
Kubernetesクラスターに常駐し、Deploymemtにある内容に合うようにPodの状態を制御し、クラスターの中でPodを立ち上げる役割を持つ。
Service
ユーザーからのリクエストをContainerに送り、トラフィックのコントロールをする。用途により、いくつかのタイプがある。
代表的なサービスのタイプ
ClusterIP
Kubernetesクラスターの外から来たトラフィックは受け入れない。クラスター内の中のPod同士のトラフィックを仲介する
LoadBalancer
クラスターの外にLBを構築し、LB経由で外から来たトラフィックを受け入れる。クラウドベンダーのマネージドサービスを想定している場合が多く、たとえばOKE（Oracle Container Engine for Kubernetes）であれば、OCI（Oracle Cloud Infrastructure）のLBの自動構築が行われる。
宣言的オペレーション
これを理解すると、より"Kubernrtesらしいノリ"を理解できるとのこと（ by @hhiroshellさん）
コンテナを３つあげて、Podは２個、トラフィックは、、という内容を全部コードで書くことができる、ということです。
それは何かすごいの？と私なんかは思ってしまいますが、、
- Kubernetesクラスターの上スライドの情報がGitで管理できる
- 障害時のバージョン管理が楽
- Kubectlを実行するだけでよいので、運用オペレーションが楽
- 個別のクラスターに依存しないので、同じファイルをアプライして実行できる
など、コードで表現できることによるメリットは多いようです。
４．Oracleが提供するマネージドKunernetes
最後の章となりましたが、Oracleもマネージドサービスを提供しています。
Oracle Engine for Kubernetes（OKE）とOracle Cloud Infrastructure Registry（OCIR）
ここではOracleも他社と同じようにマネージドサービス提供していますよ、という意味を込めてスライド掲載だけしておきます。
OracleマネージドKubernetesの優位性①：パフォーマンスと可用性
OCI上に構築されることになるので、Availability Domain（AD）を横断してクラスター構成し、高可用性を実現することもできます。そのほかにも、OCIのAD間、AD内の低レイテンシでつなぐN/Wの恩恵なども受けることができます。マイクロサービスで設計されるときなど、サービス同士の通信を支える通信速度は大事になってきます。
OracleマネージドKubeenetesの優位性②：周辺サービスとの組み合わせ
Kunernetesだけで全てが完結するということはありません。APIアクセスによる管理・セキュリティ、大量のストリーミングをさばく基盤などと組み合わせることができます。
OracleマネージドKubernetesの優位性③：価格
OKEやOCIRを利用すること自体に特別な費用は発生しません。そこで利用されるIaaSのみが課金の対象となります。コントロールプレインも課金対象外なので、純粋にユーザーの方が利用するIaaSが対象です。
事例
OKEを活用し、AIプラットドームを開発されている会社にGAUSS様がいらっしゃいます。画像解析アルゴリズムはさまざまな画像データを使って精度をあげていく必要があるため、画像認識のアプリに繰り返しアップデートをかけていくということです。そのため、高い頻度でシステムを更新する必要性があるためコンテナとの相性がいいわけですね。記事があったのでのせておきます。
まとめ
いかがでしたでしょうか？
みなさまの理解にお役に立てていれば幸いです。
ちなみに、、やさしくわかる「Docker基礎」では、4000字lostをしてしまったので、今回はかなりこまめに保存しながら書き進めました...
それでは、また！
