10分くらいでわかる、KubernetesとEKSの何が便利なのか

注意

この記事は、実運用したことのない、Kubernetes初心者が調べた結果に基づき作成しています。
間違い・誤解などありましたら、コメントや編集リクエストでご連絡ください。

TL;DR / 結論から先に言うと

• コンテナをクラウドでそのまま動かそうとすると困る
  • n台動かしたいコンテナが、今クラウド全体で何台動いているのかとか
  • デプロイするときに、コンテナを立ち上げたり落としたりする順番・タイミングとか
  • コンテナに割り当てるロードバランサ、ストレージなどの作成とか
  • 他にもいろいろ
• Kubernetesはクラウド全体のコンテナ周りを一元管理してくれるので便利
  • どの環境で、どんなコンテナがどれだけ動いているかとか、把握してくれるので便利
  • コンテナ周りをどんな構成にしたいか、yml形式で書いてkubectlコマンドで渡す
  • 運用者の指示した形になるように、コンテナ周りを一元的に操作してくれるので便利
• EKSはKubernetesのうち、コンテナを一元管理してくれるところをマネージドで使えるので便利
  • Kubernetesのうち、コンテナを動かすマシンは自分たちで管理する
• ECSも似たことをしてくれるけど、自発的にロードバランサとか作ったりしてくれない
  • Kubernetesは自分からロードバランサとか作りに行ったりもする
  • ECSはFargateが使えるけど、EKSは自前でEC2立てる
• ECSの方が構成が比較的シンプルで、扱うコンテナの種類が少なければ便利なこともある

この記事で説明したいこと

• Kubernetesの何が便利なのか
• なぜ使うのか
• どんな問題を解決してくれるのか
• お お よ そ どんな構成や、仕組みで動いているのか
• EKSの何が便利なのか
• ECSとEKSの違いは何か

この記事で説明しないこと

• 細かいコマンドや設定の仕方
• 細かいアーキテクチャ・構成の説明
• ベストプラクティスや、実運用上での事例
• Serviceなど、細かいKubernetesのコンポーネント
• サービスメッシュなど

そもそもコンテナって何

• コンテナ型仮想化と呼ばれる技術がある
• Dockerなどを通じてホストOSの上でOSっぽい環境(コンテナ)を動かす
• Dockerなどは、コンテナを動かすための環境を提供するミドルウェア
• VM Wareや、Virtual Boxは「ホスト型仮想化」というものもある
  • これは、OSの上に、まるまるOSを動かす
• コンテナは、ホストOSのカーネルなどを共有して使う
  • そのため、ホスト型より軽く動く
  • カーネルなどは、すでにホストOSが立ち上げている物を使うので起動も速い
  • なので、単一のアプリ単位ごとにコンテナを立ち上げたりしやすい
• コンテナ自体が一つのOSのように動くので、コンテナ同士は分断されていて影響を受けにくい
• アプリの実行に必要な構成や依存関係を、コンテナにひとまとめにしておくことができる
  • なので、実行してみたら動かないとか起きにくい

おおざっぱなコンテナ動作のイメージ

コンテナの困りごと

• 手元(ローカル)の環境ででコンテナを動かす分には便利
• 使いたいアプリケーションがすぐ使える
• ただ、運用するとなると困ることが出てくる

例えば、以下のような構成を考えてみます。

• AWS上で動かしたい
• バックエンドサーバを3コンテナ動かして
• DBサーバを1コンテナ動かしたい
• できるだけ 複数の場所(リージョン/AZ)に均等に分散させたい

手元の環境をそのままAWSに持って行った図

持って行けたは持って行けました。
ただ、運用していく中で次のような困りごとが出てきそうです。

• 各地域に、どのコンテナが何台動いているって誰が把握しているの？
• 地域ごとに均等に配置するために、毎回人力で確認しないとダメ？
• コンテナを新しいものに置き換えるときどうしよう？
• 既存のコンテナ落としたり、立ち上げたりするタイミング・順番・依存関係
• 毎回、各コンテナごとに手順書つくってやってもいいけど、だいぶ大変
• 死んでるコンテナ検知して、置き換える仕組み作らないと
• コンテナに割り当てるリソースも管理しないと
• ストレージとか、ロードバランサとかコンテナごとに用意・管理しないと
• ネットワークや、アクセス権限もコンテナごとに用意・管理しないと
• などなど・・・

だいぶ大変そうです。

コンテナ自体の運用の課題と、
ネットワークやロードバランシングなどコンテナ周りの運用の課題が、
いくつかありそうですね

そこで、Kubernetes

どんな構成・運用をするか、決めないといけないことは人が決めるとしても、
コンテナごとに管理・操作していたら、情報や手順が散らかって大変です。

せめて、コンテナやコンテナ周りのことを 一元的に管理したいところです。
できれば、決めたことに沿って、コンテナやコンテナ周りの操作を自動化してほしいですね。

Kubernetesを導入すると、そんなコンテナ周りの一元管理、一元操作をしてもらうことができます。
Kubernetesは、k8sと略して記述されることもあるようです。

Kubernetesはざっくり、どんな感じに動くのか

コンテナ周りのことを一元的に管理してくれるやつ

まずは、コンテナ周りのことを一元的に管理してほしいところについて、知りたいです。

コンテナ周りの全体像を把握して、一元的に管理してくれるのが**Kubernetes Master(s)**です。
Kubernetes Master自体が、複数台構成で動く場合があります。

このKubernetes Masterが、環境全体のコンテナの稼働状況などを把握していて、
コンテナの稼働状況などに基づいて、運用者が指示した理想の形になるように
コンテナを配置したり、削除したりする指示を出します。

コンテナ周りの状況を把握してコントロールするので、
コントロールプレーンというものに分類されます。

(一方で、コンテナを動かす環境のことを データプレーンと呼びます)

実際にコンテナを動かすやつ

コンテナを管理してくれるやつは、何となくわかったので、
次は、コンテナを動かすところ(データプレーン)
についてどうすれば良いか知りたいところです。

単にコンテナを動かす環境だけ用意されても、
Kubernetes Masterは、手を出すことができません。

Kubernetes Masterから操作できるような仕組みが必要なはずです。

Kubernetes Mastersが管理する、コンテナを動かす環境は、
Kubernetes Nodeと呼ばれています。

1Node = 1マシン単位です。
Nodeとして動かすマシン自体は、仮想マシンでも、物理マシンでも問題ありません。

このNodeの上では、
Masterの指示に沿ってコンテナや、コンテナの集まりを操作するソフト(kubelet)と、
Dockerなどのコンテナ型仮想環境が主に動いています。

コンテナ、扱いやすい単位でまとめたくない？

じゃあ、そのKubernetes Nodeの上で個別にコンテナが動くの？

でも、複数のコンテナをグループ化して扱いたい場合とかあるんじゃない？
個別に指定しなきゃダメ？

とか思うところがあると思います。

ということで、Kubernetes Node上では、
複数(1台以上)のコンテナをグループにして管理できる仕組みがあります。

グループは、Podという単位でまとめられています。
コンテナは何かしらのPodに属しています。

まとめる単位は、Mastersへの設定次第で決められます。
Pod内のコンテナは、IPやストレージなどを共有することになります。

Podの単位でまとめておくことで、まとめた操作指示をしたり、管理できたりします。

Nodeの集まり

Nodeの集まりは、Kubernetes Clusterと呼ばれます。

コンテナ管理するところと、動かすところができたので

Kubernetes Masersの指示のもとに、Kubernetes Nodeが動けるようになりました。

Kubernetes Mastersは、NodeやPodの状況に応じて、
コンテナを作ったり、再作成したり、落としたりすことなどを、Nodeに指示できます。

じゃあ、どうやってKubernetes Masterに指示を出すの?

Kubernetes Masterに、
どういう感じにコンテナ周りを構成してほしいか伝えると、
その構成になるように操作してくれるということはわかりました。

では、どのような感じでKubernetes Masterにコンテナ周りの構成を伝えれば良いんでしょう。
ざっくり、以下のような流れで伝えます。

• yaml形式でコンテナ周りをどんな構成にしたいか、記述する
• その設定ファイルは、マニュフェストと呼ばれる。
• kubectlコマンドを使って、設定をKubernetes Masterに反映する
• Kubernetes Masterは反映された内容を元に、NodeやPodを操作する
• もちろんkubectlとKubernetes Mastersの間には認証でアクセス制御できる

※ 今回は概要の理解が目的なので、細かい操作や設定方法はばっさり割愛させてもらいます。

実際の運用では、個々人がkubectlを実行するよりも、
JenkinsなどCI/CD環境が実行する場合が多いようです。

その他コンテナ周りについて

コンテナ周りのもろもろについて、

• ロードバランシングなどのトラフィック管理構成
• 操作できるコンテナのアクセス権限管理
• ストレージなどの設定・割り当て
• デプロイの方法・手順など

などなど、本当にいっぱいあります・・・・
これらも同様に、マニュフェストファイルに記述して、Kubernetes Masterに作成・管理してもらうことになります。
(今回、詳細は割愛します。)

Kubernetes って？ ああ！

これらを踏まえた上で、Kubernetesというと、
前述の構成や、仕組み(と、未説明のコンポーネントなど)
全体を指すことになります。

Kubernetes自体の運用が大変なんでしょう？

大変。(らしい)

なので、AWSやGCP、AzureなどでマネージドのKubernetesサービスが提供されています。

私の場合だと、AWSの知識しかほぼないため、Amazonが提供するマネージドのKubernetesサービス。
Amazon EKSについて説明します。

EKSって？

正式名称は、Amazon Elastic Container Service for Kubernetes

Amazonが提供するマネージドのKubernetesサービスです。

■ Amazon EKS
https://aws.amazon.com/jp/eks/

EKSの何が便利なの？

Kubernetes Master(コントロール プレーン)に当たる部分を、
マネージドで運用してくれます。

マネージドサービスなので、以下のことは勝手にやってくれます。

• Kubernetes Masterの更新・パッチの適用
• 死んでしまったKubernetes Masterの検出、置き換え
• 複数AZへのKubernetes Masterの配置・構成
• などなど

また、 AWSの提供する他サービスとの連携も、できるようになっています。
例えば、ロードバランサや、ストレージなどをKubernetesが作成する場合、
AWSマネージドのサービスを選択できます。

そのため、それらの運用の一部をAWSに任せることができます。

一方で、Kubernetes Node(データプレーン)として、
運用するマシンは自分で管理・運用する必要があります。

案ずるより生むが易し

Amazon EKSは公式チュートリアルがあるので、簡単に体験できます。

■ Amazon EKS の使用開始
https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/getting-started.html

この、チュートリアルをオススメする理由は以下の通りです。

• VPCや、SGの作成など、Kubernetesを触る本筋以外のところは、自動化されている
• 自動作成するCloudFormationのテンプレートが用意されている
• マニュフェストファイルも用意されており、コンテナを起動するまでが手軽に試せる
• 試した環境の削除も楽

また、Classmethodさんの解説記事が、とてもわかりやすかったです。

※上記の公式ドキュメントの内容の方が新しく、インストールするツール(コマンド)の
バージョンに差異があるため、両方を見比べながら実践すると良いと思います。

※現在は東京リージョンでも試せるはずですが、Amazon EKS 最適化 AMI が東京で提供されていないので、AMIのリージョン間コピーが必要です

■ 【まずは触って体験】リリース直後のAmazon EKSでサンプルアプリケーションを動かしてみた
https://dev.classmethod.jp/cloud/aws/eks-getting-started/

Amazon ECSと何が違うの？

Amazonには、EKSと同じくコントロールプレーン(コンテナを管理するやつ)の
サービスとして、ECS(Elastic Container Service)というものがあります。

どのような違いや、特徴があるんでしょうか。

私が感じた、主な違いは以下の通りでした。

• ECSでは、コンテナを動かすところ(データプレーン)にFargateが採用できる
• Fargateはコンテナを動かすところもマネージドで提供してくれるサービス
• EKSではFargateを使用することは現状できない。
• ECSは、ロードバランサやストレージなどのリソースを、自分から作成しない
• ECSは既に作成済みのロードバランサや、ストレージを割り当てる形
• EKSは仕組みの中で、ロードバランサやストレージなどのリソースを作成することがある
• ECSは、コンテナの管理に特化しているので、シンプルな構成を、シンプルに扱える
• 複数の多種多様なコンテナを運用しないのであれば、ECSの方がシンプルに扱うことができる
• などなど

また、以下の記事で
「ECSはAWS上でしか動かない。」(からEKSも提供した)
とあったのが印象的でした。

■ AWSはなぜ、ECSがあるのにKubernetesのサービスを始めたのか、コックロフト氏に聞いた
https://www.atmarkit.co.jp/ait/articles/1806/11/news029.html

まとめ

• Kubernetesは複数コンテナを管理する必要がある時に、頼れる
• コンテナを一元的に管理、操作できる
• コンテナ周りのネットワークやストレージも一元的に管理・操作できる
• なので、多数の複数コンテナを扱う、マイクロサービス運用する場合とかに便利そう
• AWSでコンテナの種類がそんなに多くなければ、ECSの方がシンプルで良さそう

この記事を書くためにやったこと

Kubernetes完全ガイド(第二版)を半分くらい読んで、
https://book.impress.co.jp/books/1118101055

前述の、EKSチュートリアルを実践しました。
■ 【まずは触って体験】リリース直後のAmazon EKSでサンプルアプリケーションを動かしてみた
https://dev.classmethod.jp/cloud/aws/eks-getting-started/

Kubernetes完全ガイドは、紹介に書かれているように本当に網羅的に、
わかりやすく書かれていてよかったです。

また、チュートリアルの解説もわかりやすく助かりました。

この記事ができた経緯

先日、とらのあなさんのLTイベントに参加させてもらいました。

もともと、Kubernetesを導入する理由と、利点がざっくりわからなかったので、
調べて、10分くらいにまとめて発表をしました。
せっかくなので、その内容を元に、ドキュメント形式でも残しておこうと思います。

【とらのあな主催】オタクが最新技術を追うライトニングトークイベント４回目
https://yumenosora.connpass.com/event/120688/

■ 10分くらいで雑に理解する KubernetesとEKS (ページスクロールで原稿が読めます。)
https://speakerdeck.com/masachaco/10fen-kuraideza-nili-jie-suru-kubernetestoeks