Kubernetes超初心者入門５　コンテナアプリとパッケージ　まとめることは大切です。

SHARE

こんにちは、サイオステクノロジーの前田です。今回はアプリケーション、Kubernetesを利用したコンテナアプリケーションについてお話します。

Docker等でコンテナ一つを一時的に利用するだけのアプリケーションの場合には考慮する必要はないですが、複数のコンテナを利用したり、いろいろな設定があるマニフェストを利用する場合は、管理＆運用が難しくなります。管理や運用を楽にするためコンテナアプリケーションもパッケージ化を行い利用しやすい形にしています。今回はコンテナアプリケーションの利用を中心にした話をします。

目次

目的と目標

  • 目的

    • KubernetesのアプリケーションのパッケージであるHelmとマニフェストファイルの違いを理解する

  • 目標

    • ネームスペースを作成する
    • コンテナアプリケーションをHelmを利用してデプロイする
    • アプリケーションデプロイしたときに永続ストレージを確認する
    • アプリケーションのマニフェストファイルを確認する
    • コンテナアプリでマニフェストファイル、Helmチャート,Operatorの3種類があることを知る

コンテナアプリ基礎

基礎編としては、コンテナイメージとマニフェストファイルと、デプロイする空間を理解します。

コンテナアプリケーションをKubernetesにデプロイする場合は、コンテナイメージをコンテナファイル（dockerファイル）で保管、マニフェストファイル（大量のYAML）を作成して、ネームスペースに適応して、デプロイされます。

コンテナイメージ

コンテナイメージは、コンテナを実行するためのテンプレートでdokcerイメージとも言われるものです。dockerhub,Quay.io等のコンテナリポジトリにイメージを保管して利用します。

  • コンテナイメージ
    • OSとプロセスをインストールし　「すぐに実行可能なソフトウェアパッケージ」にしたものになります。
      • httpdやnginx,java,mysql等様々なものがあります。
      • コンテナイメージはサーバと違い、シンプルなプロセスを利用する形で構成され、複数のコンテナを利用してコンテナアプリケーションとして形成される場合が多いです。
    • コンテナイメージを作成する場合にはコンテナファイル（Dockerfile）からビルドしてイメージを作成していきます。

マニフェストファイル

  • マニフェストファイル（構成ファイル）
    • コンテナアプリケーションとしてどのような構成を示すファイルです。
      • ワークロード系では、コンテナの起動数や、デプロイするノードの設定、リソース等を設定します。
      • サービス系では、ネットワークを設定します。
      • コンフィグやストレージ系では、環境設定、機密情報、永続化ボリュームを設定します。
    • 一つのファイルにまとめたりKubernetsのリソース（API）毎にマニフェストファイルを作成したりします。

  • マニフェストファイルの中のリソース

    • マニフェストの中にリソースが数多くあり覚えるのが大変です。deplroymentにreplicasetがあり、そのなかにpod等々、複雑に連携しているものもあります。
    • リソース例
      • Pod
      • Replicaset
      • Deployment
      • Configmap
      • PersistentVolumeClaim
      • ServiceAccount
  • サンプルマニフェストファイル
    • wordpresssample
      • 上記参考URLを確認していただくと、いくつかのyamlファイルが存在しており、その中のkindでリソースの種類が分かれており、いろいろと設定しております。

ネームスペース

  • ネームスペース（デプロイする空間）
    • アプリケーションを分けてデプロイすることができる空間です。
    • 起動時には4つ存在しています。何も指定しない場合defaultを利用します。
      • default:
      • kube-system
      • kube-public
      • kube-node-lease

 

基礎編を確認し、想像より理解する量が多いと思った方もおられるでしょう。

１から全部作るのは、Kubernetes専門で詳しい方でないと学習コストが高すぎて、Kubernetesの利用をあきらめる原因になる場合があります。その問題を解消するために、HelmやOperatorという形で提供することが増えています。

コンテナアプリ　パッケージ

コンテナファイルやマニフェストファイルの形は、全ての利用者に優れた形式ではありません。そのためKubernetesにアプリケーションをデプロイする場合は利用しやすい形式のものがあります。3つ（yamlマニフェスト、Helmチャート,Operator）について比べてます。

下記はサーバやインフラエンジニアの方が直観的に対比するための表になります。

yaml（マニフェストファイル）

  • マニフェストは主にyamlで記載する場合が多く、通称ではyamlファイルともいわれます。
  • 公式にリソースそれぞれのマニフェストがあり,そちらを見ながら一行ずつ規則に沿って記載していきます。
  • Kubernetesを利用するエンジニアの壁（yamlの壁）の一つです。
    • 構成後や慣れた後に確認する側としては、この軽視であることがすごく扱いやすい（視認性が良い）です。
    • 他のものを利用しても最終的にはリソースのマニフェストが作成されます。

マニフェスト記載例

Helm（ヘルム）

  • Helmについて
    • Kubernetes アプリケーションの管理を支援します。Helm チャートは、最も複雑な Kubernetes アプリケーションの定義、インストール、およびアップグレードを支援します。
  • Helmチャート
    • アプリケーション構造を記述し、簡単なコマンドで管理で管理できます。
    • 各社がKubernetesにデプロイしやすい形式としてHelmチャートとして公開しています。
  • 良く利用する環境変数は外部設定可能になっており、一部の設定を変更する形式になっています。

下記の図はArtifacthubに存在するwordpressのHelmチャートになります。インストール方法や設定などがあり、yamlマニフェストより簡単にインストールや設定変更が行えます。

CICDツールを利用する場合もHelmチャートにして利用するということも多いため、Kubernetsアプリケーションの全体像を理解するときはHelmを利用することもお勧めします。

  • 参考URL
    • ヘルムチャートハブ　https://artifacthub.io/
    • 公式　https://helm.sh/ja/

 

Operator（オペレータ）

  • 利用のみで考えると一番良い形がOperatorになります。
  • OperatorはHelmやマニフェストファイルと少し違います。オペレータはインストールだけでなく運用面も含んだ構成ファイルの元という形で提供します。そのため直観的な理解方法としては、●●アプリのインストールは●●オペレータのインストールと同じはなく、●●オペレータを利用してインストールという形になります。
    • アプリケーションのマニフェスト管理はオペレータになるため、Helmやyamlマニフェスト形式と違い直接マニフェストファイルの変更ができない場合が多いです。
  • オペレータは成熟レベルにより、インストールの自動化、アップグレードの自動化、フルライフサイクルの自動化と運用の自動化の対応レベルが違います。なるべく高い運用レベルのオペレータを利用することにより、プロダクション環境の構成の冗長化等の考慮を少なくすることができます。
  • Operatorはレベル２以上を作る場合には、専門の知識が必要になります。

 

  • 参考URL
    • オペレータハブ　https://operatorhub.io/
    • https://operatorframework.io/

 

Helmを利用したアプリのデプロイ

helmを利用してサンプルアプリケーションをデプロイしていきます。

概要

今回の利用するアプリケーションは『etherpad』というウェブベースのコラボレーション型リアルタイムエディタをデプロイしていきます。

Googleドキュメント等と同じようにブラウザベースで記入することができます。説明会とか不特定多数が参加している場合でリアルタイムに情報更新しながら、編集等で複数人が記載する場合に利用します。

 

ehterpadはAPP＋DBの構成のアプリケーションになります。DBを利用しているためコンテナ再起動時にデータが消えないように永続ストレージを利用します。

  • etherpad参考URL
    • https://etherpad.org/
  • 環境情報
    • EKS
    • EBS（永続ストレージ利用）
    • クライアント端末 bash
  • インストール概要
    • Helmクライアントの設定
    • Helmを利用してデプロイ
    • 正常性確認
    • アンインストール

Helmクライアントの設定

  • クライアントの設定

    • クライアント（AWS CloudShell等）にアクセスします。
    • 環境変数の設定します。
      • export VERIFY_CHECKSUM=false
    • helm ダウンロードします。
      • curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
    • 環境の再リロードもしくは再ログインします。
  • 正常性確認
    • バージョン情報を確認します。
      • helm version
        • 結果表示（下記のような結果が出ることを確認します）
          • version.BuildInfo{Version:”v3.9.2″, GitCommit:”1addefbfe665c350f4daf868a9adc5600cc064fd”, GitTreeState:”clean”, GoVersion:”go1.17.12″}

Helmを利用してデプロイ

参考etherpad: https://artifacthub.io/packages/helm/truecharts/etherpad

  • helmを利用したデプロイ
    • ネームスペースの作成します。
      • kubectl create namespace testhelm
    •  ヘルプリポジトリを登録します。
      • helm repo add truecharts https://charts.truecharts.org/
    • ヘルムを使用したインストール
      • helm install my-etherpad truecharts/etherpad --version 8.0.19 -n testhelm
    • インストールしたHelmを確認します。
      • helm list -n testhelm
        • deployedと表示されていたら成功です。
  • デプロイ確認
    • ネームスペース確認
      • kubectl get all -n testhelm
        • 複数のリソースがデプロイされます。
  • 外部公開設定
    • 外部公開用にサービス（ロードバランサー）を作成します。
      • kubectl expose deployment my-etherpad --type=LoadBalancer --name=etherpad-service-loadbalancer --port=80 -n testhelm
    • 作成されたサービスを確認します
      • kubectl get svc -n testhelm
      • EXTERNAL-IPの情報をコピーします。

正常性確認

  •  ストレージ確認
    • 永続ストレージを確認します。
      • kubectl get pv -n testhelm
    • 永続ストレージ要求を確認します。
      • kubectl get pvc -n testhelm
    • 999GBのストレージが3つ作成されていて、アプリケーションの永続ストレージが存在することを確認します。
      • AWSのEBSの画面を確認すると下記のように表示されます。
  • サービス確認
    • ブラウザにアクセスします。
    • 作成したサービスのEXTERNAL-IPの情報をブラウザに入力します。
    • 新規作成を押して、notepadを表示します。
    • 可能ならば複数人で文字入力して、いろんな場所からリアルタイムに資料が更新されるのを確認します。

アンインストール

etherpadのアンインストールを行います。永続ストレージが残っている場合は手動削除を行います。

  • リソースの削除
    • etherpadの削除をアンインストールします。
      • helm uninstall my-etherpad -n testhelm
  • リソース削除確認
    • リソースを確認します
      • kubectl get all -n testhelm
        • No resources と表示されるまで何回かコマンド実行します。
  • 永続ストレージの確認＆削除
    • 永続ストレージリソースを確認します。
      • kubectl get pv -n testhelm
        • 全部消えていたら問題なし、残っている場合は削除します。
    • 永続ストレージ要求リソースを確認します。
      • kubectl get pvc -n testhelm
        • 残りのリソースを確認します。
    • 永続ストレージ要求を削除します。
      • kubectl delete pvc ●● -n testhelm

おわりに

Kubernetesを利用する方により、コンテナアプリケーションの種類は変わります。

  • 開発者の中のアーキテクチャ担当はマニフェストファイルを利用するため、ある程度の理解が必要でしょう。
  • CI/CD担当者やSREエンジニアは、マニフェストファイルからCI/CD等の利用しやすい形やプロダクション利用にしていくため深い知識が必要でしょう。
  • クラスター管理者はマニフェストファイルを作成するほどの理解は必要なく、Helmで設定する変数や、Operatorを利用してアプリケーションを利用することに注力していきます。

以前は最初期はマニフェストを理解するという大きなハードルがありましたが、OperatorやHelmを利用することで簡易にプロダクション環境で利用できるようになっています。Kuberrnetesを以前学習して諦めた方も、Helmを利用してKubernetesで開かれる新世界を見ていただけたらと思います。

この記事がKubernetesに悩まれている方の解決になれば幸いです。

ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？

役に立った 役に立たなかった

1人がこの投稿は役に立ったと言っています。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

前の記事

Ansible Automation Controller(旧…

次の記事

可視化ツールGrafana9.0の新機能紹介