Oracle Cloud Hangout Cafe Season7 #1「Kubnernetes 超入門」(2023年6月7日開催)

「Oracle Cloud Hangout Cafe」コミュニティについて

「Oracle Cloud Hangout Cafe」(通称「おちゃかふぇ」/以降、OCHaCafe)は、日本オラクルが主催するコミュニティの1つです。定期的に、開発者・エンジニアに向けたクラウドネイティブな時代に身につけておくべきテクノロジーを深堀する勉強会を開催しています。

OCHaCafeのテーマは、Oracleの製品や技術に特化せず、オープン/デファクト・スタンダードを基準に選定して、参加される方々がいかなるプラットフォームを利用している場合でも、必ずスキルアップに役立てられる内容を趣旨としています。

【Oracle Cloud Hangout Cafe これまでの資料と動画】

本連載について

OCHaCafeは、2018年12月から開始して、この5年間、多くの方にご参加いただきました。そして、この5年間でたくさんの有益なコンテンツが蓄積されました。本連載では、その中からご好評いただいたテーマを選択し、ダイジェスト(全6回)でお送りします。

• 第1回「Kubernetes 超入門」
• 第2回「IaC のベストプラクティス」
• 第3回「Kubernetesのネットワーク」
• 第4回「Pythonで作るAPIサーバー」
• 第5回「Observability 再入門」
• 第6回「Kubernetes のオートスケーリング」

本連載にあたり各回の内容は実施時の発表内容をベースとしますが、技術の進化によって執筆時に変更する場合もあります。その場合は、実施時の発表内容とは異なりますので、予めご了承ください。

なお、今回からはOCHaCafeダイジェストの第2弾となります。2021〜2022年に開催されたOCHaCafeの解説をメインとした第1弾については、下記のリンクより参照ください。

【「Oracle Cloud Hangout Cafe (OCHaCafe)」ダイジェスト】

アジェンダ

今回は、コンテナとコンテナオーケストレーションの関係を学び、Kubernetesのコンポーネントとその仕組みを掴み、Kubernetesクラスタにサンプルアプリケーションの環境を構築する過程を見ていきます。

• コンテナとコンテナオーケストレーション
  • これまでのアプリケーション開発
  • OS/ライブラリとアプリケーションの分離
  • 仮想マシンとコンテナの違い
  • OS/ライブラリとアプリケーションの統合
  • Docker 実践 ～ Build ～
  • Docker 実践 ～ Ship ～
  • Docker 実践 ～ Run ～
  • Docker 実践 ～ Build/Ship/Run ～
  • コンテナを支えるオーケストレーション
• Kubernetesコンポーネント
  • Control Plane & Node
  • Pod
  • ReplicaSet & Deployment
  • Service
  • Ingress
  • Volume & PersistentVolume & PersistentVolumeClaim
  • ConfigMap & Secret
  • Namespace & Label
• Kubernetesクラスタ構築&アプリケーションデプロイ
  • クラスタ構築
  • WordPressを動かしてみる

発表資料と動画については、下記のリンクを参照してください。
【資料リンク】
【動画リンク】

コンテナとコンテナオーケストレーション

最初に、これまでのアプリケーションを稼働させるインフラからコンテナへの流れを説明し、仮想マシンとコンテナの仕組みの違い、コンテナにおけるBuild/Ship/Runを理解した上で、コンテナとコンテナオーケストレーション(Kubernetes)の関係を見ていきます。

これまでのアプリケーション開発

インフラ基盤
これまで、開発したアプリケーションを動かす主なインフラ基盤は、以下の通り4つあると思います。

• 物理マシン：物理サーバでアプリケーションを稼働
• 仮想マシン：物理サーバ上の仮想マシンでアプリケーションを稼働
• 仮想マシン(クラウド)：クラウド上の仮想マシンでアプリケーションを稼働
• コンテナ：物理マシン、仮想マシンをクラスタとしてコンテナでアプリケーションを稼働

それぞれの環境によって、開発、基盤、運用のスタイルも変わります。

それぞれロールに応じて、以下のような役割があります。

• 開発者：ソースコードの作成、更新
• インフラエンジニア：開発/検証/ステージング/本番環境におけるインフラの構築や管理
• 運用者：サービスとしてシステムの管理

OS/ライブラリとアプリケーションの分離

アプリケーションは、物理や仮想マシンのOSやライブラリ上で稼働します。その稼働するアプリケーションは実行環境に依存するため、環境差異が原因で他の環境では稼働するが、本番環境では稼働しないなどの障害が発生する可能性があります。例えば、OS やパッチのバージョンが異なる、このライブラリがなかった、関係ないものがインストールされている、などです。

仮想マシンにおいては、仮想マシンイメージが各ベンダー製品特有のものであったり、容量が重く、可搬性が低いことによる運用への影響もあります。例えば、OS/ライブラリのアップデートに人手や時間を要することでアプリケーションのリリースに影響する、などです。

仮想マシンとコンテナの違い

ここから、コンテナの話に入ります。最初に、仮想マシンとコンテナの違いを見ていきます。

仮想マシンは、ハードウェア上にハイパーバイザーがあり、その上でゲストOSとしてカーネルを含め、1台のサーバのように動かす仕組みです。そのため、隔離性は高いですが、起動に時間を要し、オーバヘッドが大きくなります。ハードウェアのCPU/MEMが多ければ多いほど、複数の仮想マシンを起動できます。

コンテナは、ハイパーバイザーがなく、ホストとなるサーバOSのカーネルを共有してプロセス空間を分離し、その中でアプリケーションを動かす仕組みです。そのため、隔離性は低いですが、起動が高速でオーバヘッドが小さくなります。カーネルを共有するということは、カーネルの脆弱性がコンテナに、コンテナの脆弱性がカーネルに影響する可能性もありますが、こうしたセキュリティ面をカバーするプロダクトもあるので、併用することが一般的です。仮想マシンと同様にハードウェアのCPU/MEMが多ければ多いほど、複数のコンテナを起動できます。

OS/ライブラリとアプリケーションの統合

ビルド(Build)
ここからは、コンテナの基本となるBuild/Ship/Runについて説明します。仮想マシンと同様にコンテナにもイメージがあります。このイメージをプロセス空間(コンテナ)に展開して動かします。このイメージにはOS/ライブラリとアプリケーションが含まれています。ビルド処理を行い、コンテナイメージとしてパッケージされます。

OS/ライブラリとアプリケーションがパッケージされるという点では仮想マシンイメージと同じと捉えられます。異なる特徴としては、技術がオープンソースソフトウェアのためベンダーロックインを回避し、容量がはるかに軽いためポータビリティ性が高いところです。

シップ(Ship)
コンテナイメージは、軽量のため専用のコンテナイメージレジストリに格納して、保存、共有できます。仮想マシンイメージに比べて、ネットワーク負荷やストレージの容量消費も抑えられます。

ラン(Run)
DockerやKubernetesなどのコンテナプラットフォーム上で、コンテナイメージを基にコンテナを起動します。イメージおよびプラットフォームもオープンソースソフトウェアがベースとなっているため、ベンダーロックインを回避できます。

Docker 実践 ～ Build ～

コンテナの基本となるBuild/Ship/Runの概要を掴んだところで、ここからはDockerを利用して、実際にどのようにBuild/Ship/Runを実行するのかを見ていきます。

Dockerはアプリケーションを軽量でポータブルなコンテナイメージにパッケージ化し、コンテナとしてアプリケーションを実行できるオープンソースソフトウェアで、異なる環境で一貫した動作が保証されます。コンテナイメージを展開したコンテナは、必要なコード、ライブラリ、システムツールなどを含んでおり、インフラストラクチャから分離してアプリケーションを実行します。Dockerは開発、配布、運用のプロセスを簡素化し、これらをより迅速かつ効率化できます。

コンテナイメージの作成にはDockerfileを利用します。下図のDockerfileはCentOS7上にNginxを起動する例です。手順としては、CentOS上にNginxをインストールするのと同じです。「COPY index.html /usr/share/nginx/html」の箇所は、ビルド時にローカルにある index.htmlを/usr/share/nginx/htmlディレクトリにコピーするということです。そして「ENTRYPOINT ["/usr/sbin/nginx", "-g", "daemon off;"]」は、コンテナ起動時にNginxのプロセスを起動するということです。

このDockerfileを「docker image build」コマンドで実行して、コンテナイメージを生成します。

ここで、コンテナイメージの構造とコンテナ起動時の構造を見ていきます。コンテナイメージは、Dockerfileの命令に従ってレイヤーを形成する構造です(下図)。ベースイメージがCentOS7のレイヤーとなり、その上に各命令の内容が積み重なる仕組みです。ベースイメージの容量やレイヤー数が多くなるとコンテナイメージの全体の容量にも影響が出るため、軽量化を考慮する必要があります。コンテナイメージの軽量化については多種多様なナレッジがあるためここでは説明を省きますが、インターネット上にはたくさんあるので調べることをお勧めします。

コンテナ起動時は、書き込み可能なレイヤーが追加されます。このレイヤーで実行した内容を保存するには「docker container commit 」コマンドで保存することもできますが、コンテナのイミュータブルな利用方法としては推奨されていません。

実際にビルドコマンドを実行すると、下図のようになります。

Docker 実践 ～ Ship ～

ビルドしたコンテナイメージをコンテナイメージレジストリにアップロードする場合は「docker image push」コマンドを実行します。コンテナイメージレジストリからイメージをダウンロードする場合は「docker image pull」コマンドを実行します。また、イメージレジストリおよびリポジトリにはパブリック/プライベートがあるため、環境に合わせて利用できます。コンテイメージにタグを付与することで、レジストリ内でバージョン管理もできます。

Docker Hubを例に、コンテナイメージのプッシュとプルを見ていきます。Docker HubはDockerの公式レジストリで、Dockerイメージの共有と管理するためのプラットフォームです。ユーザーはここでイメージの検索やダウンロード、また自分のイメージをアップロードして公開することもできます。アカウントを作成すれば無料で利用できますが、有料で利用すると無料枠より豊富な機能やサポートを利用できます。

アカウント作成後に、Docker Hubにログインします。

下図は、コンテナイメージをプッシュとプルを実行した場合の例です。

Docker 実践 ～ Run ～

ローカルでビルドしたコンテナイメージやコンテナレジストリからプルしたコンテナイメージを基に「docker container run」コマンドを実行して、コンテナを起動します。

下図はコンテナを起動して、curlコマンドでNginxのデフォルト画面を表示する例です。

Docker 実践 ～ Build/Ship/Run ～

Build/Ship/Runを整理すると、Dockerfileでコンテナイメージを作成、生成されたコンテナイメージをコンテナイメージレジストリに格納し、そこで保存および共有、コンテナプラットフォーム上でコンテナ起動という流れになります。

コンテナを支えるオーケストレーション

ここまで、Build/Ship/Runを中心にコンテナ単体での話をしてきました。コンテナ単体では、コンテナ自体が落ちたり、コンテナプラットフォームを支えるホストの物理マシンや仮想マシンに障害が発生して稼働が停止した場合の対処がなく、システム自体利用できなくなります。復旧も手動で実行することが否めません。この状態でのプロダクション利用は厳しい状況です。

コンテナやそれが稼働するホストが停止した場合でも自動修復して、サービス無停止による継続やアプリケーションをサービス無停止の状態でデプロイ可能な環境を構築する上でコンテナーオーケストレーションが必要となります。

ここからは、そのコンテナオーケストレーションの1つであるKubernetesにフォーカスします。

Kubernetesは、Google社内のコンテナーオーケストレーションシステムであるBorgからインスパイアされて開発されたOSSのコンテナーオーケストレーションです。K8sという略称もあります。現在は、CNCF(Cloud Native Computing Foundation)で管理され、多数の企業が参加するコミュニティで開発が続けられています。

Kubernetesは、コンテナ単体ではできないことを担います。下図にKubernetesの主な役割と実現できることを示します。

Kubernetesには、宣言的オペレーションとしてマニフェストに定義した内容を、内部コンポーネントのコントローラーがあるべき理想の状態と認識し、その状態を維持および変化があった場合に定義状態に収束するReconciliation Loop(調整ループ)という仕組みがあります。この仕組みについては、後半で説明します。

この仕組みにより、コンテナ単体ではできないことを自律的に実現します。

Kubernetesは、分散処理基盤と考えるとイメージが湧きやすいかと思います。たくさんのサーバをクラスタとして束ねて、その上でコンテナとしてアプリケーションを稼働します。

これまで、1台のサーバ上でプロセスとしてアプリケーションを動かしていましたが、たくさんのサーバを束ねて、コンテナというプロセスとしてアプリケーションを動かして、リソースが不足した場合はクラスタのサーバ数を増やしてリソースを増強する仕組みを実現できます。

Kubernetesクラスタ上では、DevOps、機械学習、IoTなど色々な分野のアプリケーションをコンテナアプリケーションとして稼働できます。