Charmed Kubernetes – SRA OSS Tech Blog https://www.sraoss.co.jp/tech-blog/ OSS専門の技術ブログ。PostgreSQL、Zabbixを中心に10種類以上のOSSの解説、アップデート情報、運用ヒントを提供。 Fri, 30 Oct 2026 08:23:18 +0000 ja hourly 1 https://wordpress.org/?v=7.1.3 https://www.sraoss.co.jp/tech-blog/wp-content/uploads/2018/07/blog-icon-150x150.png Charmed Kubernetes – SRA OSS Tech Blog https://www.sraoss.co.jp/tech-blog/ 32 32 Charmed Kubernetes の永続ストレージ https://www.sraoss.co.jp/tech-blog/kubernetes/charmed-kubernetes-persistent-volume/ Mon, 14 Mar 2022 04:00:50 +0000 https://www.sraoss.co.jp/tech-blog/?p=9008 前回の記事では、Canonical Kubernetes ディストリビューション Charmed Kubernetes の特長、構築方法などを紹介しました。

Kubernetes を用いて簡単にコンテナとしてアプリケーションをデプロイ・削除をできるのがメリットですが、コンテナを削除するとコンテナ内のデータも削除されてしまいます。そのため、データベースのようなステートフルアプリケーションを利用する場合には、データの永続化が必要となります。

今回は Charmed Kubernetes の永続ストレージ機能を紹介し、Charmed Kubernetes 上でのステートフルアプリケーションの構築について紹介します。

Kubernetes の永続ストレージ

Kubernetes の Podを削除すると Pod 内に保存されていたデータも一緒に削除されてしまいますので、データの永続化はできません。Kubernetes ノード上の領域を Pod にマウントすることで、Pod を削除した後もデータはノードに残るため、データの永続化は可能ですが、Pod が別ノードに再スケジュールされた場合にはデータの再利用ができないというデメリットがあります。

Kubernetes ノードとは別に外部ストレージを利用することで、Pod が削除されてもデータは外部ストレージに存在するため、データの永続化が可能です。また、外部ストレージはノードとは独立して存在しており、Pod が別のノードで再起動したとしてもデータが外部に存在するため、データの再利用が可能です。

Kubernetes でデータ永続化を実現するために、以下のリソースを利用します。

  • PersistentVolume (PV)
  • PersistentVolumeClaim (PVC)
  • StorageClass

事前に永続ボリューム (PersistentVolume) リソースを Kubernetes 上に作成しておき、Pod デプロイ時に PersistentVolumeClaim によって PersistentVolume が要求されると、Kubernetes は事前に作成しておいた PersistentVolume から要求に適したものを Pod に割り当てます。このような方法では、予め PersistentVolume を作成する手間がかかり、また、PersistentVolumeClaim の要求以上の容量の PersistentVolume が割り当てられてしまうという問題があります。

これに対して、PersistentVolume を動的に作成する仕組み Dynamic Provisioning を利用することができます。Dynamic Provisioning は StorageClass を利用し、PersistentVolumeClaim によって PersistentVolume が要求されたタイミングで PersistentVolume を動的に作成し、Pod に割り当てます。Dynamic Provisioning を利用することで、事前に PersistentVolume を作成する手間が省けます。また、PersistentVolumeClaim の要求よりも大きい容量の PersistentVolume が作成されることも回避できます。

本稿では Charmed Kubernetes 上で Dynamic Provisioning を利用したデータ永続化のソリューションを紹介します。

Charmed Kubernetes の永続ストレージ

Charmed Kubernetes で以下の方法を用いてデータの永続化を実現することができます。

クラウドのストレージソリューション

Charmed Kubernetes のクラウド基盤統合機能を利用すると、クラウドベンダーによって提供されているストレージソリューションをすぐに使用できます。

例えば、OpenStack 統合機能を有効にして Charmed Kubernetes をデプロイすると、cdk-cinder という名前の StorageClass が自動的に作成されます。

Ceph

Ceph Charm を用いてデプロイした Ceph クラスタを外部ストレージとして使用し、PersistentVolume を作成します。

NFS

NFS Charm を用いてデプロイした NFS サーバを外部ストレージとして使用し、PersistentVolume を作成します。

ベアメタルにデプロイされた Kubernetes では、クラウドの機能を利用できないため、Ceph や NFS を利用することになります。本稿では、Juju を用いて Charmed Kubernetes 上に Ceph を構築し、ステートフルアプリケーションのデータの永続化を実現する方法を紹介します。

前提条件

Charmed Kubernetes のデプロイが既に完了していることが前提となっています。今回は AWS 上にデプロイした Charmed Kubernetes を利用します。(デプロイ方法はこちらを参照)

Ceph ストレージの構築

Ceph はオープンソースの分散ストレージソフトウェアです。

Kubernetes の永続ストレージに Ceph を利用すると、拡張可能な高可用ストレージを実現することができます。本節では、Juju を用いた Ceph ストレージの構築方法を説明します。

デプロイ済みの Charmed Kubernetes クラスタにアクセスし、ノード状態を確認します。まだデプロイしていない場合は、こちらのデプロイ手順を参照してください。

$ kubectl get node
NAME               STATUS   ROLES    AGE     VERSION
ip-172-31-54-236   Ready    <none>   9m48s   v1.23.4
ip-172-31-7-84     Ready    <none>   9m43s   v1.23.4
ip-172-31-90-192   Ready    <none>   9m43s   v1.23.4

セキュリティの観点から、モデルを分けることをお勧めしますが、本稿は Charmed Kubernetes 上で Ceph による Dynamic Provisioning を検証することが目的なので、Kubernetes と Ceph を同一 モデルにデプロイします。

Charmed Kubernetes がデプロイされているモデルに切り替えます。

$ juju switch k8s

Ceph Monitor ノードをデプロイします。

Ceph Monitor はクラスタの管理、状態監視を行うコンポーネントです。高可用性を実現するために、3台以上の奇数台が必要です。ここでは、3台の Ceph Monitor ノードをデプロイします。

$ juju deploy -n 3 ceph-mon

Ceph OSD ノードをデプロイします。

Ceph OSD はデータの保存、データの冗長化などを行うコンポーネントです。
Juju の ceph-osd Charm では、--storage オプションに2種類のストレージを設定できます。

  • osd-devices: データを格納するストレージ
  • osd-journals: ジャーナルを格納するストレージ

--storage オプションは <storage pool>,<size>,<number> 形式で指定します。

  • storage pool: ストレージプールを指定します。ストレージプールはクラウド基盤に依存します。指定しない場合は、クラウド基盤のデフォルトのストレージプールを使用します。AWS のデフォルトのストレージプールは ebs となります。
  • size: 各ボリュームのサイズを指定します。
  • number: ボリュームの数を指定します。

ここでは、3台の Ceph OSD ノードをデプロイします。各 OSD ノードに2つのデータ用のボリューム（50GB）と1つのジャーナル用のボリューム（10GB）を作成します。

$ juju deploy -n 3 ceph-osd --storage osd-devices=50G,2 --storage osd-journals=10G,1

Ceph Monitor と Ceph OSD の関連付けを行います。

$ juju add-relation ceph-osd ceph-mon

RBD で作成した PersistentVolume のアクセスモードが ReadWriteOnce となりますので、アクセスモード ReadWriteMany の PersistentVolume を利用する場合には、CephFS をデプロイする必要があります。利用する場合には、以下のコマンドを実行し、CephFS のデプロイおよび関連付けの設定を行います。

$ juju deploy -n 1 ceph-fs
$ juju add-relation ceph-fs ceph-mon

Charmed Kubernetes で Ceph ストレージを利用するために、関連付けの設定を行います。

$ juju add-relation ceph-mon:admin kubernetes-master
$ juju add-relation ceph-mon:client kubernetes-master

Charmed Kubernetes と Ceph の関連付けの設定が完了したら、kubectl get sc を実行し、StorageClass が表示されていることを確認します。
※cephfs ストレージクラスは、ceph-fs をデプロイした場合にのみ表示されます。

$ kubectl get sc
NAME                PROVISIONER         RECLAIMPOLICY   VOLUMEBINDINGMODE  ALLOWVOLUMEEXPANSION  AGE
ceph-ext4           rbd.csi.ceph.com    Delete          Immediate          true                  2m39s
ceph-xfs (default)  rbd.csi.ceph.com    Delete          Immediate          true                  2m39s
cephfs              cephfs.csi.ceph.com Delete          Immediate          true                  2m39s

Pod の状態を確認します。
※cephfs の Pod は、ceph-fs をデプロイした場合にのみ表示されます。

$ kubectl get pod
NAME                                            READY   STATUS    RESTARTS   AGE
csi-cephfsplugin-927cv                          3/3     Running   0          18s
csi-cephfsplugin-b6q66                          3/3     Running   0          22s
csi-cephfsplugin-provisioner-6f7ffd894d-b2sh4   6/6     Running   0          101s
csi-cephfsplugin-provisioner-6f7ffd894d-d5b9x   6/6     Running   0          101s
csi-cephfsplugin-provisioner-6f7ffd894d-kqvxn   6/6     Running   0          101s
csi-cephfsplugin-vqgtb                          3/3     Running   0          15s
csi-rbdplugin-fsh7g                             3/3     Running   0          15s
csi-rbdplugin-nt2lq                             3/3     Running   0          22s
csi-rbdplugin-provisioner-7dffff7f4d-8l8l5      7/7     Running   0          101s
csi-rbdplugin-provisioner-7dffff7f4d-wmvct      7/7     Running   0          101s
csi-rbdplugin-provisioner-7dffff7f4d-z7nm9      7/7     Running   0          101s
csi-rbdplugin-ts8rw                             3/3     Running   0          19s

これで Ceph クラスタを Charmed Kubernetes の外部ストレージとして使用し Dynamic Provisioning を実現するための準備が完了です。

スケールアウト

Ceph のスケールアウトとは、新しいノードまたはデバイスを追加することによって利用可能な容量を拡張することです。本節では Ceph のスケールアウト手順について説明します。

Ceph ストレージの容量を拡張するには、Ceph OSD ノードを追加するか、既存の Ceph OSD ノードにストレージを追加します。

まず、既存のストレージの割り当てを確認します。

$ juju storage
Unit        Storage id      Type   Pool  Size   Status    Message
ceph-osd/0  osd-devices/0   block  ebs   50GiB  attached  
ceph-osd/0  osd-devices/1   block  ebs   50GiB  attached  
ceph-osd/0  osd-journals/2  block  ebs   10GiB  attached  
ceph-osd/1  osd-devices/3   block  ebs   50GiB  attached  
ceph-osd/1  osd-devices/4   block  ebs   50GiB  attached  
ceph-osd/1  osd-journals/5  block  ebs   10GiB  attached  
ceph-osd/2  osd-devices/6   block  ebs   50GiB  attached  
ceph-osd/2  osd-devices/7   block  ebs   50GiB  attached  
ceph-osd/2  osd-journals/8  block  ebs   10GiB  attached

新しい Ceph OSD ノードを追加します。

$ juju add-unit ceph-osd -n 1

新しいノード ceph-osd/3 が追加されていることを確認します。

$ juju storage
Unit        Storage id       Type   Pool  Size   Status    Message
ceph-osd/0  osd-devices/0    block  ebs   50GiB  attached  
ceph-osd/0  osd-devices/1    block  ebs   50GiB  attached  
ceph-osd/0  osd-journals/2   block  ebs   10GiB  attached  
ceph-osd/1  osd-devices/3    block  ebs   50GiB  attached  
ceph-osd/1  osd-devices/4    block  ebs   50GiB  attached  
ceph-osd/1  osd-journals/5   block  ebs   10GiB  attached  
ceph-osd/2  osd-devices/6    block  ebs   50GiB  attached  
ceph-osd/2  osd-devices/7    block  ebs   50GiB  attached  
ceph-osd/2  osd-journals/8   block  ebs   10GiB  attached  
ceph-osd/3  osd-devices/10   block  ebs   50GiB  attached  
ceph-osd/3  osd-devices/9    block  ebs   50GiB  attached  
ceph-osd/3  osd-journals/11  block  ebs   10GiB  attached

$ juju status ceph-osd
Model  Controller      Cloud/Region   Version  SLA          Timestamp
k8s    k8s-controller  aws/us-east-1  2.9.22   unsupported  15:39:18+09:00

App       Version  Status  Scale  Charm     Store     Channel  Rev  OS      Message
ceph-osd  15.2.14  active      4  ceph-osd  charmhub  stable   513  ubuntu  Unit is ready (2 OSD)

Unit         Workload  Agent  Machine  Public address  Ports  Message
ceph-osd/0*  active    idle   13       3.83.100.242           Unit is ready (2 OSD)
ceph-osd/1   active    idle   14       3.238.52.73            Unit is ready (2 OSD)
ceph-osd/2   active    idle   15       3.235.171.220          Unit is ready (2 OSD)
ceph-osd/3   active    idle   17       54.82.234.9            Unit is ready (2 OSD)

Machine  State    DNS            Inst id              Series  AZ          Message
13       started  3.83.100.242   i-074dcc388f5b35c1b  focal   us-east-1d  running
14       started  3.238.52.73    i-0b2d721800fd923d6  focal   us-east-1c  running
15       started  3.235.171.220  i-0e9916138314d204b  focal   us-east-1f  running
17       started  54.82.234.9    i-0cf8cad9824868068  focal   us-east-1a  running

既存の Ceph OSD ノードにストレージを追加するために、juju add-storage コマンドを実行します。以下のコマンドを実行し、ceph-osd/0 ノードに 50GB の新しいボリュームを追加します。

$ juju add-storage ceph-osd/0 osd-devices=50G,1

ceph-osd/0 ノードに 50GB のボリュームが追加されていることを確認します。

$ juju storage
Unit        Storage id       Type   Pool  Size   Status    Message
ceph-osd/0  osd-devices/0    block  ebs   50GiB  attached  
ceph-osd/0  osd-devices/1    block  ebs   50GiB  attached  
ceph-osd/0  osd-devices/12   block  ebs   50GiB  attached  
ceph-osd/0  osd-journals/2   block  ebs   10GiB  attached  
ceph-osd/1  osd-devices/3    block  ebs   50GiB  attached  
ceph-osd/1  osd-devices/4    block  ebs   50GiB  attached  
ceph-osd/1  osd-journals/5   block  ebs   10GiB  attached  
ceph-osd/2  osd-devices/6    block  ebs   50GiB  attached  
ceph-osd/2  osd-devices/7    block  ebs   50GiB  attached  
ceph-osd/2  osd-journals/8   block  ebs   10GiB  attached  
ceph-osd/3  osd-devices/10   block  ebs   50GiB  attached  
ceph-osd/3  osd-devices/9    block  ebs   50GiB  attached  
ceph-osd/3  osd-journals/11  block  ebs   10GiB  attached

アプリケーションをデプロイしてみる

Charmed Kubernetes の永続ストレージの動的プロビジョニング機能を検証するために、ステートフルアプリケーションをデプロイしてみます。

本稿では、ステートフルアプリケーションとして PostgreSQL を扱います。

Kubernetes 上で PostgreSQL を動かすために、PostgreSQL Operator が必要になります。PostgreSQL Operator は PostgreSQL のデプロイや管理を自動化するためのソフトウェアです。

今回は検証目的で Charmed Kubernetes 環境向けに開発された PostgreSQL Charmを利用して PostgreSQL を構築します。現時点では、PostgreSQL  Charm はスケーリングとフェイルオーバにのみ対応しており、バックアップやリストア・PITR などの管理は手動で行う必要があるため、本番環境での利用はお勧めしません。

本番環境で PostgreSQL をデプロイする場合は、以前の記事で紹介した Crunchy PostgreSQL Operator または Zalando PostgreSQL Operator を利用すると良いと思います。

Charmed Kubernetes  上に Juju チャームをデプロイするために、デプロイ済みの Charmed Kubernetes を Juju に登録する必要があります。

juju add-k8s コマンドを実行し、Charmed Kubernetes 環境を登録します。ここでは、my-k8s という名前で 登録します。

$ juju add-k8s my-k8s

pg-controller という名前でコントローラーをデプロイします。

$ juju bootstrap my-k8s pg-controller

PostgreSQL をデプロイするためのモデルを作成します。モデル名と同じ名前の Namespace が Kubernetes に作成され、PostgreSQL がこの Namespace にデプロイされます。

ここで pg-model という名前のモデルを作成します。

$ juju add-model pg-model

次に、PostgreSQL をデプロイします。

PostgreSQL Charm の –storage オプションに2種類のストレージを設定できます。

  • pgdata: データベースのデータを格納するストレージ
  • logs: PostgreSQL のログを格納するストレージ
$ juju deploy postgresql-k8s -n 3 --storage pgdata=20G --storage logs=1G

上記コマンドを実行すると、primary 1台、replica 2台 の PostgreSQL クラスタが作成されます。

$ kubectl get pod -n pg-model
NAME                             READY   STATUS    RESTARTS   AGE
modeloperator-7896f7f67d-pwch5   1/1     Running   0          4m17s
postgresql-k8s-0                 1/1     Running   0          2m14s
postgresql-k8s-1                 1/1     Running   0          2m14s
postgresql-k8s-2                 1/1     Running   0          2m14s
postgresql-k8s-operator-0        1/1     Running   0          3m8s

PersistentVolumeClaim (PVC) と PersistentVolume (PV) を確認してみましょう。
PostgreSQL Charm の PVC によって PV が自動的に作成されていることを確認します。

$ kubectl get pvc -n pg-model
NAME                               STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
logs-2c7ce802-postgresql-k8s-0     Bound    pvc-265cd94c-77ec-4862-b021-b9d199326ef6   1Gi        RWO            ceph-xfs       2m52s
logs-2c7ce802-postgresql-k8s-1     Bound    pvc-6f71aa9a-77fd-4de5-93a8-bcd4e88fe35d   1Gi        RWO            ceph-xfs       2m52s
logs-2c7ce802-postgresql-k8s-2     Bound    pvc-cbca4843-f12f-49e3-ae89-5436d9791819   1Gi        RWO            ceph-xfs       2m52s
pgdata-2c7ce802-postgresql-k8s-0   Bound    pvc-7b40a98c-6f00-4f64-8c0a-701ccc0515d3   20Gi       RWO            ceph-xfs       2m52s
pgdata-2c7ce802-postgresql-k8s-1   Bound    pvc-cd6415e2-2322-4b5f-89f2-640b8d65d515   20Gi       RWO            ceph-xfs       2m52s
pgdata-2c7ce802-postgresql-k8s-2   Bound    pvc-5eb9547b-e14a-42a3-9746-e012411121a7   20Gi       RWO            ceph-xfs       2m52s

$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                           STORAGECLASS   REASON   AGE
pvc-2572bd8d-286f-4ffd-89b6-e22a95a11873   20Gi       RWO            Delete           Bound    controller-pg-controller/storage-controller-0   ceph-xfs                6m30s
pvc-265cd94c-77ec-4862-b021-b9d199326ef6   1Gi        RWO            Delete           Bound    pg-model/logs-2c7ce802-postgresql-k8s-0         ceph-xfs                3m8s
pvc-5eb9547b-e14a-42a3-9746-e012411121a7   20Gi       RWO            Delete           Bound    pg-model/pgdata-2c7ce802-postgresql-k8s-2       ceph-xfs                3m6s
pvc-6f71aa9a-77fd-4de5-93a8-bcd4e88fe35d   1Gi        RWO            Delete           Bound    pg-model/logs-2c7ce802-postgresql-k8s-1         ceph-xfs                3m7s
pvc-7b40a98c-6f00-4f64-8c0a-701ccc0515d3   20Gi       RWO            Delete           Bound    pg-model/pgdata-2c7ce802-postgresql-k8s-0       ceph-xfs                3m8s
pvc-cbca4843-f12f-49e3-ae89-5436d9791819   1Gi        RWO            Delete           Bound    pg-model/logs-2c7ce802-postgresql-k8s-2         ceph-xfs                3m5s
pvc-cd6415e2-2322-4b5f-89f2-640b8d65d515   20Gi       RWO            Delete           Bound    pg-model/pgdata-2c7ce802-postgresql-k8s-1       ceph-xfs                3m7s

Replica の数を減らして、データが残るか検証します。

$ juju remove-unit postgresql-k8s --num-units 1

Pod が削除されても PVC と PV が削除されないことを確認します。

$ kubectl get pod -n pg-model
NAME                             READY   STATUS    RESTARTS   AGE
modeloperator-7896f7f67d-pwch5   1/1     Running   0          6m22s
postgresql-k8s-0                 1/1     Running   0          4m19s
postgresql-k8s-1                 1/1     Running   0          4m19s
postgresql-k8s-operator-0        1/1     Running   0          5m13s

$ kubectl get pvc -n pg-model
NAME                               STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
logs-2c7ce802-postgresql-k8s-0     Bound    pvc-265cd94c-77ec-4862-b021-b9d199326ef6   1Gi        RWO            ceph-xfs       4m37s
logs-2c7ce802-postgresql-k8s-1     Bound    pvc-6f71aa9a-77fd-4de5-93a8-bcd4e88fe35d   1Gi        RWO            ceph-xfs       4m37s
logs-2c7ce802-postgresql-k8s-2     Bound    pvc-cbca4843-f12f-49e3-ae89-5436d9791819   1Gi        RWO            ceph-xfs       4m37s
pgdata-2c7ce802-postgresql-k8s-0   Bound    pvc-7b40a98c-6f00-4f64-8c0a-701ccc0515d3   20Gi       RWO            ceph-xfs       4m37s
pgdata-2c7ce802-postgresql-k8s-1   Bound    pvc-cd6415e2-2322-4b5f-89f2-640b8d65d515   20Gi       RWO            ceph-xfs       4m37s
pgdata-2c7ce802-postgresql-k8s-2   Bound    pvc-5eb9547b-e14a-42a3-9746-e012411121a7   20Gi       RWO            ceph-xfs       4m37s

$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                           STORAGECLASS   REASON   AGE
pvc-2572bd8d-286f-4ffd-89b6-e22a95a11873   20Gi       RWO            Delete           Bound    controller-pg-controller/storage-controller-0   ceph-xfs                8m30s
pvc-265cd94c-77ec-4862-b021-b9d199326ef6   1Gi        RWO            Delete           Bound    pg-model/logs-2c7ce802-postgresql-k8s-0         ceph-xfs                5m8s
pvc-5eb9547b-e14a-42a3-9746-e012411121a7   20Gi       RWO            Delete           Bound    pg-model/pgdata-2c7ce802-postgresql-k8s-2       ceph-xfs                5m6s
pvc-6f71aa9a-77fd-4de5-93a8-bcd4e88fe35d   1Gi        RWO            Delete           Bound    pg-model/logs-2c7ce802-postgresql-k8s-1         ceph-xfs                5m7s
pvc-7b40a98c-6f00-4f64-8c0a-701ccc0515d3   20Gi       RWO            Delete           Bound    pg-model/pgdata-2c7ce802-postgresql-k8s-0       ceph-xfs                5m8s
pvc-cbca4843-f12f-49e3-ae89-5436d9791819   1Gi        RWO            Delete           Bound    pg-model/logs-2c7ce802-postgresql-k8s-2         ceph-xfs                5m5s
pvc-cd6415e2-2322-4b5f-89f2-640b8d65d515   20Gi       RWO            Delete           Bound    pg-model/pgdata-2c7ce802-postgresql-k8s-1       ceph-xfs                5m7s

おわりに

2回に渡って Canonical Kubernetes ディストリビューション Charmed Kubernetes を紹介しました。

エンタープライズ向けの機能を備えた Charmed Kubernetes は幅広いプラットフォームに対応しており、特にオンプレミスやプライベートクラウドにおいても容易に Kubernetes の環境を構築・管理できるという点は Charmed Kubernetes ならではの強みと言えます。オンプレミスやプライベートクラウドでエンタープライズ向けの Kubernetes を構築したい場合、Charmed Kubernetes は有力な選択肢だと言えるでしょう。

]]> Canonical Kubernetes ディストリビューション Charmed Kubernetes の紹介 https://www.sraoss.co.jp/tech-blog/kubernetes/charmed-kubernetes-intro/ Wed, 09 Mar 2022 05:00:03 +0000 https://www.sraoss.co.jp/tech-blog/?p=8668 クラウドサービスは企業にとって今や欠かせないもののひとつとなっていますが、セキュリティやカスタマイズの自由度の観点から、プライベートクラウドやオンプレミスを選択する企業も増えています。しかし、オンプレミスやプライベートクラウドで Kubernetes 環境を構築し、エンタープライズレベルのセキュリティと信頼性で運用するのは簡単ではないです。

Canonical 社が提供する Charmed Kubernetes はパブリッククラウドからオンプレミスまで様々なプラットフォームに対応しており、サービスのデプロイツールである Juju を用いてオンプレミスやプライベートクラウドにおいても容易に Kubernetes の環境を構築・管理できます。

本記事では、 Charmed Kubernetes の特長、構築方法および主な機能について紹介します。

Charmed Kubernetes とは

Charmed Kubernetes は Linux ディストリビューション Ubuntu の開発元であるイギリスの Canonical 社が提供するエンタープライズ向けの Kubernetes ディストリビューションです。

パブリッククラウドからオンプレミスのプライベートクラウドや仮想化基盤、ベアメタルまで、幅広いプラットフォームに対応しており、高可用性、スケーリング、ダウンタイムなしのアップグレード、暗号化通信、永続ストレージなど、エンタープライズレベルのセキュリティと管理機能を備えています。

Charmed Kubernetes の特長

Charmed Kubernetes には次のような特長があります。

クラウド基盤との統合

Charmed Kubernetes は幅広いクラウド基盤と統合することができます。統合することによって、クラウドサービスのネイティブ機能を直接使用することもできます。例えば、AWSと統合することで、AWS が提供しているストレージサービス（EBS）やロードバランサーサービス（ELB）をデフォルトで利用可能です。

アップストリーム Kubernetes の最新バージョン対応

Charmed Kubernetes はアップストリーム Kubernetes と並行してリリースされているため、アップストリーム Kubernetes の最新バージョンへアップグレードすることができ、いち早く最新機能を活用することが可能です。

幅広いプラットフォームに対応

Charmed Kubernetes は幅広いプラットフォームに対応しています。現時点では以下のプラットフォームに対応しています。

  • パブリッククラウド
    • Amazon AWS
    • Google GCE
    • Microsoft Azure
    • Oracle
    • Rackspace
    • Equinix Metal
  • プライベートクラウド
    • OpenStack
    • VMware vSphere
    • MAAS
  • ローカル
    • LXD

可用性とセキュリティに優れたエンタープライズ向けの Kubernetes

パブリッククラウドの場合は、クラウドベンダーが提供する機能によって、一部のデータセンターに障害が起きてもサービスが継続して利用できる構成となっています。一方、オンプレミスのプライベートクラウドの場合は、障害対策のためにサーバの冗長化やバックアップなどの措置が必要になります。

Charmed Kubernetes は高可用性機能を提供しており、一部のサーバに障害が起きても、Kubernetes クラスタが動作し続けます。また、Charmed Kubernetes のすべてのコンポーネントが TLS による暗号化通信を行うため、セキュアで堅牢な Kubernetes を実現できます。

Juju とは

Juju は Canonical 社が開発しているサービスをデプロイするための自動化ツールです。

Juju を用いて対応しているプラットフォーム上に複数の Ubuntu サーバの作成から、Kubernetes クラスタの構築まで、いくつかのコマンドを実行するだけで、簡単に行えます。

本記事では、Juju を用いて Charmed Kubernetes クラスタを構築し、以下の機能について動作確認を行います。

  • スケーリング
  • アップグレード
  • モニタリング
  • 永続ストレージ(こちらを参照)

検証環境およびバージョン情報

Charmed Kubernetes は様々なプラットフォーム上に構築できますが、本記事では気軽に利用できるパブリッククラウド AWS を使って Charmed Kubernetes を構築します。各ソフトウェアは投稿時点での最新バージョンを利用しています。

環境およびバージョン情報は以下の通りです。

  • Kubernetes 1.23
  • Juju 2.9.22
  • ローカルの作業環境: Ubuntu 20.04.3 LTS (Focal Fossa)

Juju がクラウドにアクセスするために、認証情報の登録が必要になります。
AWS の場合は、アクセスキーとシークレットキーが必要になりますので、事前に確認しておいてください。

Charmed Kubernetesのデプロイ

Juju のインストール

Juju をインストールします。

$ sudo snap install juju --classic

kubectl のインストール

kubectl をインストールします。

$ sudo snap install kubectl --classic

クレデンシャルの追加

Juju に AWS にアクセスするためのクレデンシャルを登録します。

$ juju add-credential aws
Select region [any region, credential is not region specific]: <任意のリージョンを指定>
Using auth-type "access-key".
Enter access-key: <アクセスキー>
Enter secret-key: <シークレットアクセスキー>
Credential "aws" added locally for cloud "aws".

登録後、以下のコマンドを実行し、AWS が登録されていることを確認します。

$ juju clouds
...
Clouds available on the client:
Cloud      Regions  Default    Type  Credentials  Source    Description
aws        22       us-east-1  ec2   1            public    Amazon Web Services
localhost  1        localhost  lxd   0            built-in  LXD Container Hypervisor

Juju コントローラーのデプロイ

Juju コントローラーをデプロイします。

Juju コントローラーは、Juju を使ってデプロイされたサービスを管理するために使用されます。以下のコマンドを実行すると、us-east-1 リージョンの EC2 インスタンスに Juju コントローラーがデプロイされます。リージョンを指定したい場合には、juju bootstrap aws/<リージョン> <コントローラー名>を実行してください。

$ juju bootstrap aws k8s-controller

デフォルトでは、 「mem=4G cores=2 」の t2.medium タイプの EC2 インスタンスが Juju コントローラーのマシンとして作成されます。CPU やメモリを変更したい場合は、デプロイ時に --bootstrap-constraints を指定することでインスタンスタイプを変更できます。

$ juju bootstrap --bootstrap-constraints "mem=8G cores=4" aws k8s-controller

モデルの作成

Juju モデルはアプリケーションやマシンがデプロイされるワークスペースです。コントローラーは複数のモデルを持つことができますが、モデルは単一のコントローラーにしか関連付けられません。各モデルは複数のマシン、サービスを持つことができます。

サービスをデプロイする際に、デフォルトでは default というモデルにデプロイされますが、サービスごとにモデルを作成することを推奨されているため、ここでは Kubernetes 専用のモデルを作成します。

$ juju add-model k8s

モデルが作成されていることを確認します。

$ juju status
Model  Controller      Cloud/Region   Version  SLA          Timestamp
k8s    k8s-controller  aws/us-east-1  2.9.22   unsupported  12:02:03+09:00

$ juju models
Controller: k8s-controller

Model       Cloud/Region   Type  Status     Machines  Cores  Access  Last connection
controller  aws/us-east-1  ec2   available         1      2  admin   just now
default     aws/us-east-1  ec2   available         0      -  admin   53 seconds ago
k8s*        aws/us-east-1  ec2   available         0      -  admin   14 seconds ago

Kubernetes のデプロイ

準備ができましたので、早速 Kubernetes をデプロイしましょう。

Juju を利用してアプリケーションをデプロイするには、Charm または Bundle を使います。

Charm を利用することで任意のマシンにアプリケーションをデプロイできます。複数アプリケーションから構成されるサービスでは、アプリケーションデプロイ後、アプリケーション同士の関連付けを設定する必要があります。Bundle は YAML 形式で記述したスクリプトファイルで、マシンの作成から、アプリケーションのデプロイ、そして関連付けまでの一連の処理を自動的にセットアップしてくれるツールです。

今回は Charm から Kubernetes をデプロイします。また、AWS のストレージサービスなどを利用するために、--overlay を利用してクラウド統合機能を有効にします。--overlay については後述します。デフォルトでは最新版がインストールされます。バージョンを指定してインストールを行う場合は後述する Bundle を使用したインストールを参照してください。

$ wget https://raw.githubusercontent.com/charmed-kubernetes/bundle/master/overlays/aws-overlay.yaml
$ juju deploy charmed-kubernetes --overlay aws-overlay.yaml --trust

すべてのアプリケーションのデプロイが完了するまで、15分~20分程度かかります。すべてのアプリケーション（App） の「Status」が「active」になったらデプロイ完了です。

juju status コマンドで状態を確認してみましょう。

App には Kubernetes の各コンポーネント、Machine には各インスタンスが表示されます。デフォルトでは 11台のマシン（インスタンス）が立ち上がり、マスタノード2台、ワーカーノード3台の Kubernetes クラスタが構成されます。

$ juju status
Model  Controller      Cloud/Region   Version  SLA          Timestamp
k8s    k8s-controller  aws/us-east-1  2.9.22   unsupported  12:27:04+09:00

App                    Version   Status  Scale  Charm                  Store       Channel   Rev  OS      Message
aws-integrator         1.15.58   active      1  aws-integrator         charmstore  stable    174  ubuntu  Ready
containerd             go1.13.8  active      5  containerd             charmstore  stable    200  ubuntu  Container runtime available
easyrsa                3.0.1     active      1  easyrsa                charmstore  stable    441  ubuntu  Certificate Authority connected.
etcd                   3.4.5     active      3  etcd                   charmstore  stable    655  ubuntu  Healthy with 3 known peers
flannel                0.11.0    active      5  flannel                charmstore  stable    619  ubuntu  Flannel subnet 10.1.6.1/24
kubeapi-load-balancer  1.18.0    active      1  kubeapi-load-balancer  charmstore  stable    866  ubuntu  Loadbalancer ready.
kubernetes-master      1.23.4    active      2  kubernetes-master      charmstore  stable   1106  ubuntu  Kubernetes master running.
kubernetes-worker      1.23.4    active      3  kubernetes-worker      charmstore  stable    838  ubuntu  Kubernetes worker running.

Unit                      Workload  Agent  Machine  Public address  Ports             Message
aws-integrator/0*         active    idle   0        54.196.183.155                    Ready
easyrsa/0*                active    idle   1        34.232.80.105                     Certificate Authority connected.
etcd/0                    active    idle   2        54.204.103.118  2379/tcp          Healthy with 3 known peers
etcd/1                    active    idle   3        3.236.214.69    2379/tcp          Healthy with 3 known peers
etcd/2*                   active    idle   4        44.198.164.226  2379/tcp          Healthy with 3 known peers
kubeapi-load-balancer/0*  active    idle   5        107.22.102.7    443/tcp,6443/tcp  Loadbalancer ready.
kubernetes-master/0*      active    idle   6        44.200.39.125   6443/tcp          Kubernetes master running.
  containerd/3            active    idle            44.200.39.125                     Container runtime available
  flannel/3               active    idle            44.200.39.125                     Flannel subnet 10.1.2.1/24
kubernetes-master/1       active    idle   7        3.83.124.151    6443/tcp          Kubernetes master running.
  containerd/0*           active    idle            3.83.124.151                      Container runtime available
  flannel/0               active    idle            3.83.124.151                      Flannel subnet 10.1.6.1/24
kubernetes-worker/0*      active    idle   8        54.160.123.197  80/tcp,443/tcp    Kubernetes worker running.
  containerd/1            active    idle            54.160.123.197                    Container runtime available
  flannel/1*              active    idle            54.160.123.197                    Flannel subnet 10.1.42.1/24
kubernetes-worker/1       active    idle   9        54.209.207.221  80/tcp,443/tcp    Kubernetes worker running.
  containerd/2            active    idle            54.209.207.221                    Container runtime available
  flannel/2               active    idle            54.209.207.221                    Flannel subnet 10.1.13.1/24
kubernetes-worker/2       active    idle   10       3.81.86.195     80/tcp,443/tcp    Kubernetes worker running.
  containerd/4            active    idle            3.81.86.195                       Container runtime available
  flannel/4               active    idle            3.81.86.195                       Flannel subnet 10.1.35.1/24

Machine  State    DNS             Inst id              Series  AZ          Message
0        started  54.196.183.155  i-02e9a6edcd5ac1cd5  focal   us-east-1a  running
1        started  34.232.80.105   i-05671fd8500a33119  focal   us-east-1f  running
2        started  54.204.103.118  i-0f28aea6be2d08e9d  focal   us-east-1d  running
3        started  3.236.214.69    i-0159b2e42b4b9c24e  focal   us-east-1f  running
4        started  44.198.164.226  i-0fd02e8e11ec1bfef  focal   us-east-1c  running
5        started  107.22.102.7    i-0bbd5a7a0ef45e4ef  focal   us-east-1b  running
6        started  44.200.39.125   i-05096429e51aeaa39  focal   us-east-1c  running
7        started  3.83.124.151    i-07c224c10603b0218  focal   us-east-1d  running
8        started  54.160.123.197  i-03a01a0e7b2bfe073  focal   us-east-1e  running
9        started  54.209.207.221  i-003d3e37b1a655e2e  focal   us-east-1a  running
10       started  3.81.86.195     i-001459c2be09d5db8  focal   us-east-1b  running

Charmed Kubernetes 設定のカスタマイズ

Charmed Kubernetes の設定をカスタマイズする方法は2つあります。

  • Bundle ファイルの使用
  • Overlay の使用

Bundle ファイルの使用

Bundle ファイルは各種設定、デプロイの手順などを記載した YAML ファイルです。Bundle ファイルを必要に応じて編集することで、設定のカスタマイズが可能です。

特定の Kubernetes バージョンの Bundle ファイルは、こらちからダウンロードできます。

一例として、v1.21 の Bundle ファイルをダウンロードし、ワーカーノードの数を変更してみます。

$ wget https://api.jujucharms.com/charmstore/v5/charmed-kubernetes-733/archive/bundle.yaml
$ vi bundle.yaml
(ワーカーノードの数を3->4に変更)
...
kubernetes-worker:
annotations:
gui-x: '90'
gui-y: '850'
charm: cs:~containers/kubernetes-worker-838
constraints: cores=4 mem=4G root-disk=16G
expose: true
num_units: 4
...

Bundle ファイルを用いてデプロイします。

juju deploy ./bundle.yaml

Overlayの使用

--overlay オプションを利用することで、デフォルトの設定にマージ、またはデフォルトの設定を上書きすることができます。

例えば、Google Cloud 統合機能を利用する場合は、以下の設定を --overlay オプションに指定します。

description: Charmed Kubernetes overlay to add native GCP support.
applications:
  gcp-integrator:
    annotations:
      gui-x: "600"
      gui-y: "300"
    charm: cs:~containers/gcp-integrator
    num_units: 1
    trust: true
relations:
  - ['gcp-integrator', 'kubernetes-master']
  - ['gcp-integrator', 'kubernetes-worker']

各クラウドサービスむけの機能統合のYAMLファイルはこちらからダウンロードできます。

Google Cloud を利用する場合は、以下の手順を実行します。

$ wget https://raw.githubusercontent.com/charmed-kubernetes/bundle/master/overlays/gcp-overlay.yaml
$ juju deploy charmed-kubernetes --overlay gcp-overlay.yaml --trust

また、一部の設定を変更したい場合も、--overlay オプションが利用可能です。

例えば、ワーカーノードのデフォルトの制約は「constraints: cores=4 mem=4G root-disk=16G」となりますが、以下の設定を --overlay に設定することで、デフォルトの設定を上書きすることができます。

$ cat myoverlay.yaml
applications:
  kubernetes-worker:
    constraints: cores=4 mem=8G root-disk=100G
    num_units: 3

$ juju deploy charmed-kubernetes --overlay myoverlay.yaml

Kubernetes クラスタへ接続

Charmed Kubernetes のデプロイが完了したら、Kubernetes に接続してクラスタの状態を確認します。

まず、マスタノードから接続設定ファイルを取得します。

$ mkdir -p .kube
$ juju scp kubernetes-master/0:config ~/.kube/config

次に、馴染みのある kubectl get コマンドを実行し、ワーカーノードや Pod の状態を確認してみます。

$ kubectl get nodes
NAME                            STATUS   ROLES    AGE   VERSION
ip-172-31-26-174.ec2.internal   Ready    <none>   21m   v1.23.4
ip-172-31-42-12.ec2.internal    Ready    <none>   19m   v1.23.4
ip-172-31-49-88.ec2.internal    Ready    <none>   22m   v1.23.4

$ kubectl get pods --all-namespaces
NAME                            STATUS   ROLES    AGE   VERSION
ip-172-31-26-174.ec2.internal   Ready    <none>   21m   v1.23.4
ip-172-31-42-12.ec2.internal    Ready    <none>   19m   v1.23.4
ip-172-31-49-88.ec2.internal    Ready    <none>   22m   v1.23.4

$ kubectl get pods --all-namespaces
NAMESPACE                         NAME                                                      READY   STATUS    RESTARTS   AGE
ingress-nginx-kubernetes-worker   default-http-backend-kubernetes-worker-6cd58d8886-nthsf   1/1     Running   0          21m
ingress-nginx-kubernetes-worker   nginx-ingress-controller-kubernetes-worker-mb75q          1/1     Running   0          21m
ingress-nginx-kubernetes-worker   nginx-ingress-controller-kubernetes-worker-vjp95          1/1     Running   0          19m
ingress-nginx-kubernetes-worker   nginx-ingress-controller-kubernetes-worker-wgbfj          1/1     Running   0          18m
kube-system                       coredns-5564855696-b2fcm                                  1/1     Running   0          25m
kube-system                       kube-state-metrics-5ccbcf64d5-5g49x                       1/1     Running   0          25m
kube-system                       metrics-server-v0.5.1-79b4746b65-bzhm5                    2/2     Running   0          25m
kubernetes-dashboard              dashboard-metrics-scraper-5cd54464bf-kc54z                1/1     Running   0          25m
kubernetes-dashboard              kubernetes-dashboard-55796c99c-r7v76                      1/1     Running   0          25m

AWS 統合機能によって、デフォルトの StorageClass が自動的に作成されていることを確認します。

$ kubectl get sc
NAME      PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
cdk-ebs   kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  26m

これで Kubernetes クラスタのデプロイは完了です。

スケーリング

Kubernetes クラスタのスケーリングとは、ワーカーノードを追加または削除することです。

Kubernetes クラスタにワーカーノードを追加することをクラスタのスケールアップ、クラスタからノードを削除することをクラスタのスケールダウンと言います。

Charmed Kubernetes では juju add-unit/remove-unit を実行することで、簡単にクラスタのスケールアップ/スケールダウンを行えます。

スケールアップ

新しいノードをクラスタに追加します。

$ juju add-unit kubernetes-worker -n 1

新しいワーカーノードが追加されていることを確認します。

$ juju status
...
kubernetes-worker/0*      active    idle   8        54.160.123.197  80/tcp,443/tcp    Kubernetes worker running.
  containerd/1            active    idle            54.160.123.197                    Container runtime available
  flannel/1*              active    idle            54.160.123.197                    Flannel subnet 10.1.42.1/24
kubernetes-worker/1       active    idle   9        54.209.207.221  80/tcp,443/tcp    Kubernetes worker running.
  containerd/2            active    idle            54.209.207.221                    Container runtime available
  flannel/2               active    idle            54.209.207.221                    Flannel subnet 10.1.13.1/24
kubernetes-worker/2       active    idle   10       3.81.86.195     80/tcp,443/tcp    Kubernetes worker running.
  containerd/4            active    idle            3.81.86.195                       Container runtime available
  flannel/4               active    idle            3.81.86.195                       Flannel subnet 10.1.35.1/24
kubernetes-worker/3       active    idle   11       174.129.117.55  80/tcp,443/tcp    Kubernetes worker running.
  containerd/5            active    idle            174.129.117.55                    Container runtime available
  flannel/5               active    idle            174.129.117.55                    Flannel subnet 10.1.7.1/24


$ kubectl get node -o wide
NAME                            STATUS   ROLES    AGE   VERSION   INTERNAL-IP     EXTERNAL-IP      OS-IMAGE             KERNEL-VERSION    CONTAINER-RUNTIME
ip-172-31-26-174.ec2.internal   Ready       44m   v1.23.4   172.31.26.174   54.209.207.221   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-42-12.ec2.internal    Ready       42m   v1.23.4   172.31.42.12    3.81.86.195      Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-49-88.ec2.internal    Ready       45m   v1.23.4   172.31.49.88    54.160.123.197   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-83-85.ec2.internal    Ready       13m   v1.23.4   172.31.83.85    174.129.117.55   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5

スケールダウン

スケールダウンするときには、ノードを安全に停止・削除するために、その Node 上で実行中の Podを退去させてから、スケールダウンを行う必要があります。

検証用の Nginx の Pod をデプロイします。

$ kubectl create deployment --image=nginx nginx

Nginx の Pod がデプロイされているワーカーノードを確認します。「ip-172-31-83-85.ec2.internal」というノード（kubernetes-worker/3）にデプロイされています。今回は、kubernetes-worker/3 を削除してみます。

$ kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE     IP         NODE                           NOMINATED NODE   READINESS GATES
nginx-85b98978db-hsbvd   1/1     Running   0          2m41s   10.1.7.2   ip-172-31-83-85.ec2.internal

ノードを安全に停止・削除するために、以下のコマンドを実行し、kubernetes-worker/3 上で動作中の Nginx の Pod を移動させ、新たに Pod がスケジュールされないようにします。

$ juju run-action kubernetes-worker/3 pause --wait
unit-kubernetes-worker-3:
  UnitId: kubernetes-worker/3
  id: "2"
  results:
    Stderr: |
      WARNING: ignoring DaemonSet-managed Pods: ingress-nginx-kubernetes-worker/nginx-ingress-controller-kubernetes-worker-rwt52
  status: completed
  timing:
    completed: 2022-02-16 04:14:20 +0000 UTC
    enqueued: 2022-02-16 04:14:16 +0000 UTC
    started: 2022-02-16 04:14:17 +0000 UTC

上記コマンドを実行すると、ノードが SchedulingDisabled になり、Pod が別のノード上で起動していることを確認できます。

$ kubectl get node -o wide
NAME                            STATUS                     ROLES    AGE   VERSION   INTERNAL-IP     EXTERNAL-IP      OS-IMAGE             KERNEL-VERSION    CONTAINER-RUNTIME
ip-172-31-26-174.ec2.internal   Ready                         55m   v1.23.4   172.31.26.174   54.209.207.221   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-42-12.ec2.internal    Ready                         53m   v1.23.4   172.31.42.12    3.81.86.195      Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-49-88.ec2.internal    Ready                         56m   v1.23.4   172.31.49.88    54.160.123.197   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-83-85.ec2.internal    Ready,SchedulingDisabled      24m   v1.23.4   172.31.83.85    174.129.117.55   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5

$ kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE    IP          NODE                           NOMINATED NODE   READINESS GATES
nginx-85b98978db-x9dzg   1/1     Running   0          2m5s   10.1.35.2   ip-172-31-42-12.ec2.internal

これで、kubernetes-worker/3 ノードを安全に削除することができます。

$ juju remove-unit kubernetes-worker/3

しばらく経つと、kubernetes-worker/3 ノードが削除されていることを確認できます。

$ juju status
...
kubernetes-worker/0*      active    idle   8        54.160.123.197  80/tcp,443/tcp    Kubernetes worker running.
  containerd/1            active    idle            54.160.123.197                    Container runtime available
  flannel/1*              active    idle            54.160.123.197                    Flannel subnet 10.1.42.1/24
kubernetes-worker/1       active    idle   9        54.209.207.221  80/tcp,443/tcp    Kubernetes worker running.
  containerd/2            active    idle            54.209.207.221                    Container runtime available
  flannel/2               active    idle            54.209.207.221                    Flannel subnet 10.1.13.1/24
kubernetes-worker/2       active    idle   10       3.81.86.195     80/tcp,443/tcp    Kubernetes worker running.
  containerd/4            active    idle            3.81.86.195                       Container runtime available
  flannel/4               active    idle            3.81.86.195                       Flannel subnet 10.1.35.1/24

$ kubectl get node -o wide
NAME                            STATUS   ROLES    AGE   VERSION   INTERNAL-IP     EXTERNAL-IP      OS-IMAGE             KERNEL-VERSION    CONTAINER-RUNTIME
ip-172-31-26-174.ec2.internal   Ready       68m   v1.23.4   172.31.26.174   54.209.207.221   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-42-12.ec2.internal    Ready       67m   v1.23.4   172.31.42.12    3.81.86.195      Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-49-88.ec2.internal    Ready       69m   v1.23.4   172.31.49.88    54.160.123.197   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5

アップグレード

この節では、Charmed Kubernetes のマスタノードとワーカーノードのアップグレード方法を説明します。その他のコンポーネント containerd、easyrsa、etcd、flannel、kubeapi-load-balancer については、ドキュメントを参照してください。

Charmed Kubernetes のワーカーノードをアップグレードするために、2つの方法があります。

  • Blue-green アップグレード: この方法では一時的により多くのリソースを利用しますが、一番安全でダウンタイムのないアップグレードを行えます。
  • In-place アップグレード: この方法では既存のノードのアップグレードを行い、追加のリソースは必要ありませんが、サービスの停止が発生します。

本番環境で利用する場合は、Blue-green アップグレードを推奨します。

ここでは、Blue-green アップグレードを利用したワーカーノードのアップグレードを検証してみます。

アップグレードする前に、Charmed Kubernetes が対応している Kubernetes のバージョン情報を確認します。今回は v1.21 の Charmed Kubernetes を v1.23 にアップグレードします。

検証用の Kubernetes クラスタをデプロイします。

$ wget https://raw.githubusercontent.com/charmed-kubernetes/bundle/master/releases/1.21/bundle.yaml
$ juju deploy ./bundle.yaml

マスタノードとワーカーノードのバージョンを確認します。

$ juju status
...
App                    Version   Status       Scale  Charm                  Store       Channel   Rev  OS      Message
containerd             go1.13.8  active           5  containerd             charmstore  stable    146  ubuntu  Container runtime available
easyrsa                3.0.1     active           1  easyrsa                charmstore  stable    395  ubuntu  Certificate Authority connected.
etcd                   3.4.5     active           3  etcd                   charmstore  stable    607  ubuntu  Healthy with 1 known peer
flannel                0.11.0    active           3  flannel                charmstore  stable    571  ubuntu  Flannel subnet 10.1.78.1/24
kubeapi-load-balancer  1.18.0    active           1  kubeapi-load-balancer  charmstore  stable    814  ubuntu  Loadbalancer ready.
kubernetes-master      1.21.9    active           2  kubernetes-master      charmstore  stable   1034  ubuntu  Restarting snap.kube-proxy.daemon service
kubernetes-worker      1.21.9    active           3  kubernetes-worker      charmstore  stable    788  ubuntu  Waiting for kube-proxy to start.

$ juju scp kubernetes-master/0:config ~/.kube/config
$ kubectl get node
NAME               STATUS   ROLES    AGE    VERSION
ip-172-31-1-0      Ready    <none>   3m1s   v1.21.9
ip-172-31-44-16    Ready    <none>   3m9s   v1.21.9
ip-172-31-92-202   Ready    <none>   3m6s   v1.21.9

まず、kubeapi-load-balancer をアップグレードします。

$ juju upgrade-charm kubeapi-load-balancer

次に、マスタノードをアップグレードします。以下のようにバージョンを指定して、upgrade を実行すると、マスタノードのアップグレードが始まります。

$ juju upgrade-charm kubernetes-master
$ juju config kubernetes-master channel=1.23/stable

$ juju run-action kubernetes-master/0 upgrade
$ juju run-action kubernetes-master/1 upgrade

最後に、ワーカーノードをアップグレードします。ワーカーノードのアップグレードを検証するために、アプリケーションをデプロイします。

$ kubectl create deployment --image=nginx nginx
$ kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE     IP          NODE              NOMINATED NODE   READINESS GATES
nginx-74d589986c-d8gqr   1/1     Running   0          6m51s   10.1.30.2   ip-172-31-30-80

ワーカーノードのバージョンを設定します。

$ juju upgrade-charm kubernetes-worker
$ juju config kubernetes-worker channel=1.23/stable
$ kubectl get node
NAME               STATUS   ROLES    AGE   VERSION
ip-172-31-14-158   Ready    <none>   25m   v1.21.9
ip-172-31-30-80    Ready    <none>   25m   v1.21.9
ip-172-31-64-109   Ready    <none>   23m   v1.21.9

新たにワーカーノードを3つ追加します。新しく追加されるワーカーノードは新しいバージョンで作成されます。

$ juju add-unit kubernetes-worker -n 3
$ kubectl get node
NAME               STATUS   ROLES    AGE     VERSION
ip-172-31-14-158   Ready    <none>   44m     v1.21.9
ip-172-31-30-80    Ready    <none>   44m     v1.21.9
ip-172-31-46-231   Ready    <none>   70s     v1.23.4
ip-172-31-46-47    Ready    <none>   4m58s   v1.23.4
ip-172-31-64-109   Ready    <none>   42m     v1.21.9
ip-172-31-81-150   Ready    <none>   2m13s   v1.23.4

旧バージョンのワーカーノードを一時停止します。

$ juju run-action kubernetes-worker/0 pause
$ juju run-action kubernetes-worker/1 pause
$ juju run-action kubernetes-worker/2 pause

すると、Nginx の Pod が新バージョンのワーカーノードに移動されます。

$ kubectl get pod -o wide
NAME                                READY   STATUS    RESTARTS   AGE     IP          NODE               NOMINATED NODE   READINESS GATES
nginx-deployment-74d589986c-d8gqr   1/1     Running   0          17m     10.1.30.2   ip-172-31-81-150

これで、旧バージョンのワーカーノード安全に削除することができます。

$ juju remove-unit kubernetes-worker/0
$ juju remove-unit kubernetes-worker/1
$ juju remove-unit kubernetes-worker/2

$ kubectl get node
NAME               STATUS   ROLES    AGE   VERSION
ip-172-31-46-231   Ready    <none>   22m   v1.23.4
ip-172-31-46-47    Ready    <none>   26m   v1.23.4
ip-172-31-81-150   Ready    <none>   24m   v1.23.4

$ juju status
App                    Version   Status  Scale  Charm                  Store       Channel  Rev   OS      Message
containerd             go1.13.8  active  4      containerd             charmstore  stable   200   ubuntu  Container runtime available
easyrsa                3.0.1     active  1      easyrsa                charmstore  stable   441   ubuntu  Certificate Authority connected.
etcd                   3.4.5     active  1      etcd                   charmstore  stable   655   ubuntu  Healthy with 1 known peer
flannel                0.11.0    active  4      flannel                charmstore  stable   619   ubuntu  Flannel subnet 10.1.66.1/24
kubeapi-load-balancer  1.18.0    active  1      kubeapi-load-balancer  charmstore  stable   866   ubuntu  Loadbalancer ready.
kubernetes-master      1.23.4    active  1      kubernetes-master      charmstore  stable   1106  ubuntu  Kubernetes master running.
kubernetes-worker      1.23.4    active  3      kubernetes-worker      charmstore  stable   838   ubuntu  Kubernetes worker running.

モニタリング

Charmed Kubernetes では Prometheus によるモニタリング機能が利用可能です。

Kubernetes では Prometheus を利用した監視がよく使われています。Prometheus がクラスタの各種メトリクスを収集し、Grafana と連携して、Grafana のダッシュボードで Kubernetes クラスタとクラスタ上で動作するアプリケーションを監視することができます。

Prometheus によるモニタリング機能を利用するために、Bundleファイルをダウンロードし、デプロイ時に --overlay オプションに指定します。

$ wget https://raw.githubusercontent.com/charmed-kubernetes/bundle/master/overlays/monitoring-pgt-overlay.yaml
$ juju deploy charmed-kubernetes --overlay monitoring-pgt-overlay.yaml

prometheus、grafana、telegraf が起動していることを確認できます。

$ juju status
Model  Controller      Cloud/Region   Version  SLA          Timestamp
k8s    k8s-controller  aws/us-east-1  2.9.22   unsupported  15:17:06+09:00

App                    Version   Status  Scale  Charm                  Store       Channel  Rev   OS      Message
containerd             go1.13.8  active  4      containerd             charmstore  stable   200   ubuntu  Container runtime available
easyrsa                3.0.1     active  1      easyrsa                charmstore  stable   441   ubuntu  Certificate Authority connected.
etcd                   3.4.5     active  1      etcd                   charmstore  stable   655   ubuntu  Healthy with 1 known peer
flannel                0.11.0    active  4      flannel                charmstore  stable   619   ubuntu  Flannel subnet 10.1.24.1/24
grafana                          active  1      grafana                charmhub    stable   51    ubuntu  Ready
kubeapi-load-balancer  1.18.0    active  1      kubeapi-load-balancer  charmstore  stable   866   ubuntu  Loadbalancer ready.
kubernetes-master      1.23.4    active  1      kubernetes-master      charmstore  stable   1106  ubuntu  Kubernetes master running.
kubernetes-worker      1.23.4    active  3      kubernetes-worker      charmstore  stable   838   ubuntu  Kubernetes worker running.
prometheus                       active  1      prometheus2            charmhub    stable   25    ubuntu  Ready
telegraf                         active  4      telegraf               charmhub    stable   44    ubuntu  Monitoring kubernetes-worker/1 (source version/commit 26e531a)
...

以下のコマンドを実行し、Grafana の URL とログイン情報を取得します。

$ juju run-action --wait grafana/0 get-login-info
unit-grafana-0:
  UnitId: grafana/0
  id: "4"
  results:
    password: 3cSfb2PshGHPLWJ4
    url: http://<IP/ Address>:3000/
    username: admin
  status: completed
...

ブラウザから上記コマンドで確認した Grafana の URL に接続し、ログインします。Grafana のダッシュボードで Kubernetes クラスタ全体のリソースの使用状況などが確認できます。

おわりに

今回は Canonical Kubernetes ディストリビューション Charmed Kubernetes の特長、構築方法、スケーリング、アップグレード、モニタリング機能について紹介しましたが、いかがでしたでしょうか。

Juju というアプリケーションのデプロイツールを用いてオンプレミスでもコマンドを実行するだけで容易に Kubernetes 環境を構築できる Charmed Kubernetes は魅力的ではないでしょうか。

次回はエンタープライズでの利用に欠かせない永続的ストレージについて説明します。

]]>