Cockpit (Linux サーバ管理ツール) で Kubernetes クラスタを管理する方法を検証してみた

こんにちは。サイオステクノロジー OSS サポート担当 Y です。

今回は Linux サーバの管理ツールである Cockpit を使って、Web UI から Kubernetes クラスタを管理する方法を検証してみました。(※以下の内容は CentOS 7.6/Cockpit 195/kubeadm 1.16.2/NGINX 1.17.5 にて検証しています。)

■はじめに

前回の記事で Cockpit を利用し Web UI から Docker コンテナを操作する方法を検証しましたが、Cockpit では Web UI から Kubernetes クラスタの管理も実施することが可能です。

今回は、Cockpit の Web UI から Kubernetes クラスタを管理する方法を検証してみました。

なお、先に結論を言ってしまうと、今回の検証にて Kubernetes クラスタの情報を参照することはできたのですが、Web UI からの一部操作 (マニフェストの適用) はエラーになってしまいました。

■インストール

まずはインストールです。以前の記事で紹介したインストール方法を参考にしながら Cockpit をインストールします。

また、今回は Kubernetes クラスタの管理に必要な cockpit-kubernetes というパッケージも一緒にインストールします。

上記 cockpit-kubernetes をインストールすると、Kubernetes の CLI ツール (クライアントツール) である kubectl を含むの依存関係のパッケージ “kubernetes-client” が一緒にインストールされます。

また、Web UI にアクセス可能にするために Firewalld で Cockpit の通信を許可する設定を実施します。

以上でインストール作業は完了です。

■kubeconfig を設定

今回は kubeadm を利用して作成した Kubernetes クラスタを管理するため、当該クラスタに接続するための kubeconfig の情報を取得します。

※kubeadm を利用した Kubernetes クラスタの構築方法については、Cockpit の話からそれてしまうため割愛致します。基本には公式ドキュメント Installing kubeadm 及び Creating a single control-plane cluster with kubeadm を参照しながら構築しています。

kubeadm を利用して作成した Kubernetes クラスタの場合は、当該クラスタへの接続用の kubeconfig が kubeadm init を実行したノード (Master) 上に “/etc/kubernetes/admin.conf” として作成されているので、当該ファイルを Cockpit サーバ上の $HOME/.kube/config ファイルとして保存します。(※今回は root ユーザで Cockpit にログインするため、root ユーザの $HOME 配下に kubeconfig を設定しています。一般ユーザで Cockpit にログインする場合、当該ユーザの $HOME 配下に .kube/config を作成する必要があります。)

念のため、この状態で kubectl コマンドを利用してリモートにある Kubernetes クラスタにアクセス可能であるか (kubeconfig を読み込むことができているか) を確認します。

上記の通り、Kubernetes クラスタの情報 (クラスタ内のノード情報) が取得できているので、kubeconfig の設定は問題無さそうです。

■Web UI への接続

インストール及び kubeconfig 設定後、Web UI (https://ip-address-of-machine:9090) にアクセスし root ユーザ (kubeconfig を設定したユーザ) でログインすると、画面左から “クラスター” というタブが選択できます。(cockpit-kubernetes をインストールしていない場合、このタブは表示されません。)

001_login

002_cluster_tab

この “クラスター” タブを選択すると以下の様な画面が表示されると思います。(kubeconfig が設定されていれば、自動的に Kubernetes クラスタに接続してくれるようです。)

003_cluster_overview

この “概要” 画面では Kubernetes クラスタ全体のリソースの状態 (CPU/Memory/Network) や、Kubernetes の各リソース (Pod/Volume/Node/Service) 等の概要を参照することが可能です。

“ノード” タブでは各ノード毎の詳細な情報やリソースの情報等を参照することが可能です。

004_node_1

005_node_2

006_node_3

“コンテナー” タブでは各 Pod 内で実行されているコンテナ毎の詳細な情報及びログを参照することや、当該コンテナ内で shell を実行することが可能です。

007_container_1

008_container_2

009_container_3

010_container_4

その他のタブでも、様々な情報を参照したり、ノードやボリュームの追加等の管理操作を Web UI から実施できるようです。

011_node_add

012_volume_add

■Web UI 上からマニフェストを適用

前述した通り、Cockpit の Web UI では Kubernetes クラスタに関する様々な情報の参照や管理操作が実施できるようですが、今回は Web UI 上でのマニフェストの適用方法を検証してみます。

なお、結論から言ってしまうと、Web UI 上でのマニフェストの適用には失敗してしまいました。明確な原因は特定できておらずあくまで推測なのですが、Cockpit (cockpit-kubernetes) に含まれている Kubernetes 関連のパッケージ (ライブラリ?) のバージョンが古いもの (v1.5.2) であることが原因である可能性がありそうです。

今回は、以下の様なマニフェスト (YAML ファイル) を作成し、Web UI 上から適用します。

予め前述したマニフェストを YAML ファイル (.yaml) として用意した上で、”概要” タブの “サービス” 欄にある “デプロイ” ボタンを選択します。

013_deploy_1

“デプロイ” ボタンを押すと、以下の様な画面が表示されます。

014_deploy_2

この画面で “マニフェストの選択…” を選択し、準備しておいた YAML ファイルを選択します。

015_deploy_3

次に “Namespace” 欄のプルダウンからデプロイ先の Namespace (今回は “default”) を選択します。

017_deploy_5

最後に “デプロイ” ボタンを選択すればマニフェストが適用できるはず…

018_deploy_6

だったのですが、以下の様なエラーになってしまいました。

019_deploy_7_error

“マニフェストをデコードできない” というメッセージなので、マニフェスト (YAML ファイル) 側に何かしらの問題がある可能性がありそうです。

実は、このマニフェストについては事前に Kubernetes クラスタ (サーバ) 側で適用可否を確認しており、その時は問題無く適用できていました。

そのため、正直なところ何が問題なのか分からなかったのですが、試しに SSH でサーバにログインし CLI (kubectl コマンド) を利用して当該マニフェストの適用を試行したところ、以下の様なエラーが出力されました。

どうやら、Cockpit をインストールしたサーバ上からこのマニフェストを適用する場合には、何かしらの問題が発生しているようです。

原因が不明ですが、とりあえずエラーメッセージに記載されている “–validate=false” オプションを付けて再度実行してみたところ、マニフェストの適用は実施できたようです。

作成した Service (30080 port で LISTEN している) に対して HTTP リクエストを実行すると、NGINX Pod (コンテナ) からも正常に応答がありました。

そのため、マニフェストの内容自体に問題は無いようにも思えるのですが、Web UI からだと “–validate=false” を指定できない (“–validate=false” に相当するボタン等が見当たらない) ので、やはり Web UI からではこのマニフェストを適用できません。

そこで、もう少し調べてみたところ、kubectl のバージョンが古いことが確認できました。

上記の通り、Kubernetes クラスタ (サーバ側) が v1.16.2 であるのに対して、kubectl (クライアント側) が v1.5.2 になっています。

そこで、試しにサーバ側と同じバージョン (v1.16.2) の kubectl を使って先程のマニフェストを適用してみました。

今回の検証の場合、kubeadm で構築した Kubernetes クラスタ (サーバ側) に、サーバ側と同じバージョンの kubectl がインストールされているので、そこから v1.16.2 の kubectl コマンドを持ってきます。

先にデプロイしていた各リソース (Service 及び Pod) を削除した上で、v1.16.2 の kubectl を使って、再度マニフェストを適用してみます。

すると今度は、”–validate=false” を指定していなくてもエラーにならず、マニフェストを適用することができました。

原因を完全に特定できた訳では無いのですが、上記の通りクライアント側 (kubectl) のバージョンが古いことが問題だったようです。

仮に、Web UI 側の処理が裏で kubectl コマンドを利用しているのであれば、その kubectl コマンドのバージョンを新しいものに変更することで、Web UI からもマニフェストを適用できるようになるかもしれません。

そこで、元々インストールされている v1.5.2 の kubectl コマンド (cockpit-kubernetes の依存パッケージである kubernetes-client パッケージに含まれている /usr/bin/kubectl) を v1.16.2 の kubectl に置き換えてみました。

しかし、Web UI 上からのマニフェストの適用は同じエラーになってしまいました。

019_deploy_7_error

このことから、Web UI 上のデプロイボタンは「裏で kubectl コマンドを実行している」という訳では無く、別途何等かの形で Kubernetes クラスタ (kube-apiserver) にリクエストを実行している状況だと思われます。

その場合、(完全に推測ですが) cockpit-kubernetes 関連のパッケージ内で利用されている Kubernetes 関連の機能 (ライブラリ?) のバージョンが古く (恐らく v1.5.2)、それが原因で Web UI 上からマニフェストを適用できないという可能性があると考えられます。しかし、kubectl コマンドと違ってそれらを簡単に新しいバージョンに置き換えることは難しそうです。

ということで、今回の検証では Web UI からマニフェストを適用することはできませんでした。(検証できていないのですが、もしかすると Kubernetes クラスタ (サーバ側) のバージョンが v1.5.2 であれば、Web UI からのマニフェスト適用が実施できるかもしれません。)

しかし、CLI (kubectl コマンド) で適用したマニフェスト (デプロイした Pod や Service) の情報は、Web UI 上から参照することができました。

020_after_deploy_1

021_after_deploy_2

■最後に

今回は Linux サーバの管理ツールである Cockpit を使って、Web UI から Kubernetes クラスタを管理する方法を検証してみました。

残念ながら、Web UI 上からマニフェストを適用することはできませんでしたが、Kubernetes クラスタの情報を参照することはできました。

Kubernetes クラスタの管理方法には複数の選択肢があると思いますが、検証用の Kubernetes クラスタのちょっとした管理の様な目的 (クラスタの情報を参照する程度) であれば、yum で簡単にインストールできる cockpit-kubernetes も選択肢の一つになるのではないでしょうか。

もちろん、今後新しいバージョンの Kubernetes にも対応していくと思いますので、今後の動向にも注目したいと思います。

>> 雑誌等の執筆依頼を受付しております。
   ご希望の方はお気軽にお問い合わせください!

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

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

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

コメント投稿

メールアドレスは表示されません。


*