クラウドサービスは企業にとって今や欠かせないもののひとつとなっていますが、セキュリティやカスタマイズの自由度の観点から、プライベートクラウドやオンプレミスを選択する企業も増えています。しかし、オンプレミスやプライベートクラウドで 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 は魅力的ではないでしょうか。
次回はエンタープライズでの利用に欠かせない永続的ストレージについて説明します。