Kubernetes入門

こんにちは、ファンデリー デザイン・システム室の平松です。

前回執筆した話[コンテナ仮想化について広く浅く (Docker)](https://www.fundely.co.jp/blog/tech/2019/11/06/180055/)の続きです。
前回のコンテナ仮想化とDockerの話にひき続き、Kubernetesの概要を解説します。
本番運用の経験はまだ少ないため、調べて自分の理解を深めつつ内容をまとめました。

コンテナ仮想化とDockerの要点 (前回のまとめ)

  • コンテナ仮想化はアプリケーションを実行環境含めそのままデータ化して運べるようにするような技術
  • コンテナ仮想化は他の形式の仮想化と比較してパフォーマンスに優れる。
  • コンテナ化したイメージは可搬性(移行のしやすさ)に優れ、環境の再現性を高める。
    → 開発環境では動いたのに本番で動かない!などの現象を防げる。
    → 逆に本番環境と同じ環境をローカル等開発環境にすぐに再現でき、時間のかかりがちな開発初期セットアップのイニシャルコストを減らせる。
  • コンテナ仮想化ツールのデファクトスタンダードは現在のところDocker。
  • Dockerにはコンテナを扱う上で必要となる様々なツール群(エコシステム)が存在する。
    → 非常に便利な反面、トータルで扱う必要があり、学習コストが高い。

Kubernetesとは

© CNCF

Kubernetesはコンテナのデプロイやスケーリング等を管理するオープンソースのソフトウェアです。(この分類のソフトウェアはコンテナオーケストレーションツールと呼ばれています。)
略してK8s、k8sと表記されるケースが多いです。読み方はクバネティス、クーベネティスあたりが有力のようで、そのように読んでいる方をよく見ます。私はクーバーネティスに近い発音で呼んでいます。
Kubernetesは元々Google社が開発していたソフトウェアで、現在はGoogle社, Apple社などの大手IT企業を始めとする520の組織(2020年1月現在)から構成されるCNCF(Cloud Native Computing Foundation)が開発・保守を行なっています。

Dockerコンテナは扱うのが単体の1つのコンテナであれば、管理はそこまで複雑ではないです。
しかし、複数個のコンテナを扱うとなると、途端に管理が複雑になってきます。
Dockerコンテナを利用することでその高い可搬性を活かして、スケーラブルなシステムを組むことが可能ですが、スケーラブルに複数のコンテナを扱おうと思うと、管理の複雑さの問題に直面します。(ここら辺はWebサーバのスケールアウト構成と似たような問題を抱えています。)
そこで、Kubernetesを始めとするコンテナオーケストレーションツールでは、コンテナ上のアプリケーション運用に必要となるリソースを抽象化して、スケーリング・デプロイ・ヘルスチェック等の管理を行いやすくしてくれています。

Kubernetesで扱うコンテナ(ランタイム)はDockerを利用するケースが多いですが、Docker以外の形式のコンテナを用いることもできます。Docker以外のランタイムとして、cri-o、rkt、gVisorなどを用いることも可能です。
一方Docker側では、元々Docker社純正のDocker SwarmというオーケストレーションツールをDockerに統合する形で提供していましたが、より多機能なKubernetesにシェアをどんどん奪われてゆき、2017年ついにDocker社自身がDocker Swarmを置き換える形でKubernetesをDockerに統合すると発表しました。
初期のKubernetesはコンテナランタイムとしてDockerのみをサポートしていたこともあり、DockerありきのKubernetesという関係でした。しかし、時代が移りCRIといったKubernetesとコンテナランタイム間の通信規格が標準化され、Docker以外のランタイムもサポートされるようになりました。Kubernetesの人気が高まり、各クラウドベンダーにKubernetes環境を提供するマネージドサービスが登場し、状況としては逆にKubernetesがデファクトとして存在し、そこにコンテナランタイムの有力な選択肢の1つとしてDockerがあるという形に変化してきています。

Kubernetesの構成

Kubernetesは1つのアプリケーションを1つのクラスターという単位で動かします。
クラスターは2種類のノード(物理マシン)で構成されます。1つがクラスター全体を制御するマスターノード、もう1つが実際にコンテナ上でアプリケーションを動かすワーカーノードです。
原則、マスターとワーカーそれぞれ1つ以上のノードが必要になり (高可用環境では各3台以上を推奨)、物理マシンが複数必要になります。ただし、開発環境用では複数マシンを用意するのは大変なため、1つのマシンの中にマスター(コンポーネント)とワーカー(コンポーネント)を入れる構成をとることも多いです。

ファンデリー デザイン・システム室ではこのような技術選定を一緒に考えるメンバーを募集しております。
興味を持ってくださった方はぜひ一度お話を聞きにきてください!

募集要項およびエントリーフォーム >

————————————————————–  

各栄養士ブログも宜しくお願い申し上げます。

赤羽ではたらく栄養士たちの日記

大阪で働く栄養士の医療機関紹介ブログ

中米グアテマラで働く栄養士の日記 ~地球の裏から~

—————————————————————