AWS
kubernetes
コンテナ
eks

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


注意 :bow:

この記事は、実運用したことのない、Kubernetes初心者が調べた結果に基づき作成しています。

間違い・誤解などありましたら、コメントや編集リクエストでご連絡ください。


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


  • コンテナをクラウドでそのまま動かそうとすると困る


    • n台動かしたいコンテナが、今クラウド全体で何台動いているのかとか

    • デプロイするときに、コンテナを立ち上げたり落としたりする順番・タイミングとか

    • コンテナに割り当てるロードバランサ、ストレージなどの作成とか

    • 他にもいろいろ



  • Kubernetesはクラウド全体のコンテナ周りを一元管理してくれるので便利


    • どの環境で、どんなコンテナがどれだけ動いているかとか、把握してくれるので便利

    • コンテナ周りをどんな構成にしたいか、yml形式で書いてkubectlコマンドで渡す

    • 運用者の指示した形になるように、コンテナ周りを一元的に操作してくれるので便利



  • EKSはKubernetesのうち、コンテナを一元管理してくれるところをマネージドで使えるので便利


    • Kubernetesのうち、コンテナを動かすマシンは自分たちで管理する



  • ECSも似たことをしてくれるけど、自発的にロードバランサとか作ったりしてくれない


    • Kubernetesは自分からロードバランサとか作りに行ったりもする

    • ECSはFargateが使えるけど、EKSは自前でEC2立てる



  • ECSの方が構成が比較的シンプルで、扱うコンテナの種類が少なければ便利なこともある


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


  • Kubernetesの何が便利なのか

  • なぜ使うのか

  • どんな問題を解決してくれるのか


  • お お よ そ どんな構成や、仕組みで動いているのか

  • EKSの何が便利なのか

  • ECSとEKSの違いは何か


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


  • 細かいコマンドや設定の仕方

  • 細かいアーキテクチャ・構成の説明

  • ベストプラクティスや、実運用上での事例

  • Serviceなど、細かいKubernetesのコンポーネント

  • サービスメッシュなど


そもそもコンテナって何 :rolling_eyes:


  • コンテナ型仮想化と呼ばれる技術がある

  • Dockerなどを通じてホストOSの上でOSっぽい環境(コンテナ)を動かす


    • Dockerなどは、コンテナを動かすための環境を提供するミドルウェア



  • VM Wareや、Virtual Boxは「ホスト型仮想化」というものもある


    • これは、OSの上に、まるまるOSを動かす



  • コンテナは、ホストOSのカーネルなどを共有して使う


    • そのため、ホスト型より軽く動く

    • カーネルなどは、すでにホストOSが立ち上げている物を使うので起動も速い

    • なので、単一のアプリ単位ごとにコンテナを立ち上げたりしやすい



  • コンテナ自体が一つのOSのように動くので、コンテナ同士は分断されていて影響を受けにくい

  • アプリの実行に必要な構成や依存関係を、コンテナにひとまとめにしておくことができる


    • なので、実行してみたら動かないとか起きにくい



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

image.png


コンテナの困りごと :frowning2:


  • 手元(ローカル)の環境ででコンテナを動かす分には便利

  • 使いたいアプリケーションがすぐ使える

  • ただ、運用するとなると困ることが出てくる

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


  • AWS上で動かしたい

  • バックエンドサーバを3コンテナ動かして

  • DBサーバを1コンテナ動かしたい

  • できるだけ 複数の場所(リージョン/AZ)に均等に分散させたい

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

image.png

持って行けたは持って行けました。 :tada:

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


  • 各地域に、どのコンテナが何台動いているって誰が把握しているの


    • 地域ごとに均等に配置するために、毎回人力で確認しないとダメ?



  • コンテナを新しいものに置き換えるときどうしよう?


    • 既存のコンテナ落としたり、立ち上げたりするタイミング・順番・依存関係

    • 毎回、各コンテナごとに手順書つくってやってもいいけど、だいぶ大変



  • 死んでるコンテナ検知して、置き換える仕組み作らないと

  • コンテナに割り当てるリソースも管理しないと


    • ストレージとか、ロードバランサとかコンテナごとに用意・管理しないと



  • ネットワークや、アクセス権限もコンテナごとに用意・管理しないと

  • などなど・・・

だいぶ大変そうです。:confounded:

コンテナ自体の運用の課題と、

ネットワークやロードバランシングなどコンテナ周りの運用の課題が、

いくつかありそうですね


そこで、Kubernetes :ship:

どんな構成・運用をするか、決めないといけないことは人が決めるとしても、

コンテナごとに管理・操作していたら、情報や手順が散らかって大変です。

せめて、コンテナやコンテナ周りのことを 一元的に管理したいところです。

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

Kubernetesを導入すると、そんなコンテナ周りの一元管理、一元操作をしてもらうことができます。

Kubernetesは、k8sと略して記述されることもあるようです。


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


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

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

コンテナ周りの全体像を把握して、一元的に管理してくれるのがKubernetes Master(s)です。

Kubernetes Master自体が、複数台構成で動く場合があります。

このKubernetes Masterが、環境全体のコンテナの稼働状況などを把握していて、

コンテナの稼働状況などに基づいて、運用者が指示した理想の形になるように

コンテナを配置したり、削除したりする指示を出します

コンテナ周りの状況を把握してコントロールするので、

コントロールプレーンというものに分類されます。

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

image.png


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

コンテナを管理してくれるやつは、何となくわかったので、

次は、コンテナを動かすところ(データプレーン)

についてどうすれば良いか知りたいところです。

単にコンテナを動かす環境だけ用意されても、

Kubernetes Masterは、手を出すことができません。

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

Kubernetes Mastersが管理する、コンテナを動かす環境は、

Kubernetes Nodeと呼ばれています。

image.png

1Node = 1マシン単位です。

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

このNodeの上では、

Masterの指示に沿ってコンテナや、コンテナの集まりを操作するソフト(kubelet)と、

Dockerなどのコンテナ型仮想環境が主に動いています。


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

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

でも、複数のコンテナをグループ化して扱いたい場合とかあるんじゃない?

個別に指定しなきゃダメ?

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

ということで、Kubernetes Node上では、

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

グループは、Podという単位でまとめられています。

コンテナは何かしらのPodに属しています。

image.png

まとめる単位は、Mastersへの設定次第で決められます。

Pod内のコンテナは、IPやストレージなどを共有することになります。

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


Nodeの集まり :family_mwgb:

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

image.png


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

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

Kubernetes Mastersは、NodeやPodの状況に応じて、

コンテナを作ったり、再作成したり、落としたりすことなどを、Nodeに指示できます。

image.png


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

Kubernetes Masterに、

どういう感じにコンテナ周りを構成してほしいか伝えると、

その構成になるように操作してくれるということはわかりました。

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

ざっくり、以下のような流れで伝えます。


  • yaml形式でコンテナ周りをどんな構成にしたいか、記述する


    • その設定ファイルは、マニュフェストと呼ばれる。




  • kubectlコマンドを使って、設定をKubernetes Masterに反映する

  • Kubernetes Masterは反映された内容を元に、NodeやPodを操作する

  • もちろんkubectlとKubernetes Mastersの間には認証でアクセス制御できる

image.png

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

実際の運用では、個々人がkubectlを実行するよりも、

JenkinsなどCI/CD環境が実行する場合が多いようです。

image.png


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

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


  • ロードバランシングなどのトラフィック管理構成

  • 操作できるコンテナのアクセス権限管理

  • ストレージなどの設定・割り当て

  • デプロイの方法・手順など

などなど、本当にいっぱいあります・・・・

これらも同様に、マニュフェストファイルに記述して、Kubernetes Masterに作成・管理してもらうことになります。

(今回、詳細は割愛します。)


Kubernetes って? ああ! :card_index:

これらを踏まえた上で、Kubernetesというと、

前述の構成や、仕組み(と、未説明のコンポーネントなど)

全体を指すことになります。

image.png


Kubernetes自体の運用が大変なんでしょう? :angel:

大変。(らしい)

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

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

Amazon EKSについて説明します。


EKSって? :eyeglasses:

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

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

■ Amazon EKS

https://aws.amazon.com/jp/eks/


EKSの何が便利なの? :kissing:

Kubernetes Master(コントロール プレーン)に当たる部分を、

マネージドで運用してくれます。

image.png

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


  • Kubernetes Masterの更新・パッチの適用

  • 死んでしまったKubernetes Masterの検出、置き換え

  • 複数AZへのKubernetes Masterの配置・構成

  • などなど

また、 AWSの提供する他サービスとの連携も、できるようになっています。

例えば、ロードバランサや、ストレージなどをKubernetesが作成する場合、

AWSマネージドのサービスを選択できます。

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

一方で、Kubernetes Node(データプレーン)として、

運用するマシンは自分で管理・運用する必要があります

image.png


案ずるより生むが易し :runner_tone2:

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と何が違うの? :hugging:

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


まとめ :smiley:


  • Kubernetesは複数コンテナを管理する必要がある時に、頼れる

  • コンテナを一元的に管理、操作できる

  • コンテナ周りのネットワークやストレージも一元的に管理・操作できる

  • なので、多数の複数コンテナを扱う、マイクロサービス運用する場合とかに便利そう

  • AWSでコンテナの種類がそんなに多くなければ、ECSの方がシンプルで良さそう


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

Kubernetes完全ガイド(第二版)を半分くらい読んで、

https://book.impress.co.jp/books/1118101055

前述の、EKSチュートリアルを実践しました。

■ 【まずは触って体験】リリース直後のAmazon EKSでサンプルアプリケーションを動かしてみた

https://dev.classmethod.jp/cloud/aws/eks-getting-started/

Kubernetes完全ガイドは、紹介に書かれているように本当に網羅的に、

わかりやすく書かれていてよかったです。

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


この記事ができた経緯 :upside_down:

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

もともと、Kubernetesを導入する理由と、利点がざっくりわからなかったので、

調べて、10分くらいにまとめて発表をしました。

せっかくなので、その内容を元に、ドキュメント形式でも残しておこうと思います。

【とらのあな主催】オタクが最新技術を追うライトニングトークイベント4回目

https://yumenosora.connpass.com/event/120688/

■ 10分くらいで雑に理解する KubernetesとEKS (ページスクロールで原稿が読めます。)

https://speakerdeck.com/masachaco/10fen-kuraideza-nili-jie-suru-kubernetestoeks