2021.01.12

Kubernetes IDE Lens は何がすごいのか

D.M. です。Kubernetes 管理ツールのご紹介です。

TL;DR

・Lens は Kubernetes の管理コマンドラインツールである kubectl を GUI で使いやすくした管理ツール。

・Lens の特徴はデスクトップアプリであること、 Lens Extension という独自拡張機能、 Workspace によるクラスターグルーピング機能の3点。既存ツールでほぼ同等の機能を持つ Rancher はサーバインストール型でブラウザで利用する点が異なる。

・Lens を利用するにはデスクトップ環境から kubectl で kubeconfig をベースにマスターノードの kube-apiserver と通信ができる必要がある。

Lens とは

Lens (レンズ)は Kubernetes クラスタの運用管理ツールです。 「 Kubernetes のための IDE 」(統合開発環境)と銘打っていますが、これで開発をするわけではなく、 IDE 的な網羅性のあるデスクトップ用の管理ツールという意味のようです。
オープンソースで無料で利用でき、 Windows 、 Mac 、 Linux の各 OS のパッケージがあります。
内部的には kubectl が Kubernetes API を利用して取得できる情報を元に GUI で表やグラフを構成しています。(Lens は kubectl を内包しており、クラスタの kubernetes のバージョンに合わせて自動でダウンロードしてくれるのでとても楽)

公式サイト
https://k8slens.dev

開発環境へつなげてみました。

Pod の一覧画面はこんな感じです。名前やコンテナ数、存続期間など kubectl get pods で取得できる内容そのままです。
kubernetes_lens_pods
Pod をクリックすると Prometheus から取ってきた情報が見られます。

lens_prometheus
使い方は直感的で迷うところがほとんどありませんでした。

Lens の強み

Github に記載された「What makes Lens special?(レンズが特別な理由は何ですか?)」をそのまま翻訳して転記します。
  • 驚くべき使いやすさとエンドユーザーエクスペリエンス
  • あらゆるプラットフォームでの統合された安全なマルチクラスター管理:数百のクラスターのサポート
  • スタンドアロンアプリケーション:クラスター内に何もインストールする必要はありません
  • レンズはどこにでも設置できるため、資格情報を整理する必要がありません
  • リアルタイムのクラスター状態の視覚化
  • 組み込みの Prometheus を利用した履歴付きのリソース使用率チャートとトレンド
  • ノードとコンテナへのスマートターミナルアクセス
  • クラスターはローカル(例:minikube)または外部(例:EKS、GKE、AKS)にすることができます
  • 大規模なクラスターを処理するために最適化されたパフォーマンス(25000ポッドを実行するクラスターでテスト済み)
  • Lens は標準の Kubernetes API を使用するため、RBAC のセキュリティは維持されます
  • Lens Extensions は、カスタムの視覚化と機能を追加して、 Kubernetes と統合するすべてのテクノロジーとサービスの開発ワークフローを加速するために使用されます
  • ポートフォワーディング
  • Helm パッケージの展開:ワンクリックで Helm チャートを参照して展開-インストール
  • Lens Extensions API を介した拡張
上記の強みは本当に特別でしょうか?

現状 Kubernetes の管理ツールではすでに Rancher が充分な強さを持っています。チーム内では2018年の段階で Rancher を使ってクラスタを管理する記事を上げていてその後も利用し続けています。

Rancher 2.0 入門!!! Kubernetesクラスタの可視化!!!


上記で記載された Lens のメリットはすでに Rancher で網羅されています。Rancher を使えばクラスタ管理コマンド(再起動、スケールアウトなど)のGUI実行、グラフィカルなリソースモニタやログ確認は全部ブラウザで実行できているし、Prometheus 連携、マルチクラスタ対応ももともと Rancher が強みとして打ち出していた内容です。そもそも Lens でできることはもう Rancher でできてるよと言わざると得ません。

既存ツールとの比較から見えてくる、本当の強み

ただ明確に違う点もいくつかあります。

Lens はまず1点目として、デスクトップ環境で気楽に始められる点があります。

とくに依存関係がなくスタンドアロンで動きます。 Rancher にはサーバが必要ですので、何らかの理由であまりサーバ側のリソースを増やしたくないというニーズには答えられるのかなと思いました。( Rancher のほうはサーバに1つセットアップしてしまえばみんなでブラウザで利用できるのでわざわざ各人の PC に入れる必要がないところがとても使いやすいです。)

また、2点目としては Lens Extension です。

Lens は当初オープンソースでしたが Mirantis 社が買収したので、( https://www.publickey1.jp/blog/20/kuberneteslensmirantis.html )今後は独自のプラグイン Lens Extensions がこれから増えていくよ!というのを謳っています。自社の Mirantis Container Cloud Lens Extension と、セキュリティツール Starboard 用のプラグインが出ていたので、おそらく各社クラウドの Kubernetes 環境に合わせた便利機能みたいなものになると思います。

Lens Extension
https://github.com/lensapp/lens-extensions

3つ目の独自機能は WorkSpace です。

Workspace を使うと複数のクラスタをグルーピングしてタブのようにしてビューを切り替えることができます。これは Kubernetes の概念ではなく Lens 独自の機能です。

使い方ですが左下に現在開いている Workspace が出ていて、そこをクリックすると Workspace の一覧へ遷移できます。ここで新規 Workspace の追加も可能です。( Default 以外に Staging と Production を作成してみました)


個別のクラスターの Settings 画面で、所属する Workspace を変更できます。

Workspace によって多くの異なるプロジェクトのクラスターを分けて管理したいなどのユースケースに対応できるようになっており、他のツールにはない独自の機能となっています。

以上の独自な点がこのツールの本当の強みと言えるのではないでしょうか。

セットアップ

インストールは公式からダウンロード( https://github.com/lensapp/lens/releases/ )して、ダブルクリックで一発です。

(2021.1.7 時点での最新バージョンは 4.0.6 でした。以下 Windows 10 にインストールしています)

利用開始するまでにハマったところ

インストールはダブルクリックだけなんだから利用開始も簡単だろう!と思いましたが、意外にも結構ハマったのでその点を共有しておきます。

初回のクラスタへの接続には+アイコンで設定を追加します。以下のような画面が出ると思います。


ここで kubeconfig を登録します。
このファイルは kubectl が動いている環境の以下のどこかにあるはず。
1. kubectl 実行時に –kubeconfig フラグで指定されたパス
2. $KUBECONFIG 環境変数に指定されたパス
3. HOMEディレクトリの隠しフォルダ ~/.kube/config
(公式情報 https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/#merging-kubeconfig-files

kubeconfig には kube-apiserver へ接続する認証情報と IP が記載されているのでそこへの接続が確保されている必要があります。

私の使っている環境のマスターノードは内部 IP 192.168.111.222, 192.168.111.223 のどちらかなので VPN をつないで接続を試みましたが、いくつかの問題に直面しました。

コマンドではキーが表示されない問題

kubeconfig は kubectl で以下のコマンドを叩くと表示することもできますがそれに騙されました。
$ kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.111.222:6443
  name: cluster1
contexts:
- context:
    cluster: cluster1
    user: user1
  name: cluster1
current-context: cluste1
kind: Config
preferences: {}
users:
- name: user1
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
これで表示されるのは全情報でありません。認証に必要な certificate などが非表示になっています。(以下のDATA+OMITTEDとREDACTEDの箇所。)

はじめはこれをそのまま Lens に登録しましたが情報がマスクされているのでもちろん接続できませんでした(笑)。知らずに Add  Cluster すると以下のようなエラーが。。。
Authentication proxy started

panic: runtime error: invalid memory address or nil pointer dereference [signal 0xc0000005 code=0x0 addr=0x0 pc=0x15119f4] goroutine

1 [running]: k8s.io/kubernetes/vendor/k8s.io/kubectl/pkg/proxy.(*Server).ServeOnListener(...)
....
何のエラーなのかさっぱりわかりません。超不親切。。

解決策として、上述のパスから正しい kubeconfig を取得して設定しました。

マスターノードへ接続できない問題

次にハマったのは通信の問題です。
私のチームでは Kubernetes を弊社の Zcom クラウド内に独自に構成しており、 kubectl が実行可能なサーバへのアクセスは VPN 接続したあとに中継サーバを経由して後ろのほうのサーバに行く必要がありました。つまりローカルのPCから直接 kubectl を実行できない状態にありました。
Lens は kubectl を利用して Kubernetes API を実行するため、 kubeconfig に記載されているマスターノードの IP が参照できなければなりません。

ただマスターノードは事情によりもう1つ別のIPアドレス 192.168.121.222 を付けており、こちらであればローカル PC から参照可能でした。
もうこれでいいだろうと思い、kubeconfig を無理やり書き換えて設定してみたところ。。
apiVersion: v1
clusters:
  - cluster:
    certificate-authority-data: [正しいもの]
    server: https://192.168.121.222:6443
こんなエラーが。。。
Authentication proxy started

2021/01/07 20:48:09 http: proxy error: x509: certificate is valid for 192.168.111.222, 192.168.111.223, 127.0.0.1, 10.43.0.1, not 192.168.110.222

502 - undefined
またしても接続不能。通信はできているようですが宛先の Destination IP も厳密にチェックしていて弾いているようです。
エラーメッセージを読むと、どうやら宛先が 127.0.0.1 への接続ならいいということなので、ローカル PC に Nginx を立てて、マスターノードのIPへ転送するようにしてみます。
その後、画面にはエラーも出ず接続された風に見えましたが、画面には何の情報も表示されませんでした。
途方に暮れて Nginx の access.log を読むと。。
"GET /api/v1/namespaces HTTP/1.1" 403
どうやらフォワードしただけでは無理なようです。宛先 IP と認証情報の整合性が取れていないと Kubernetes API は実行できないようです。(おそらくポートフォワーディングを使っても同じ理由で失敗しそう)

ここから解決編です。
仕方がないので中継するサーバの中に昔ながらのプロキシサーバ Squid をインストールして HTTP 通信を通してやることにしました。
幸い Squid はアクセスコントロールの機能がしっかりしているので、ローカル PC が VPN 経由で接続してるケースのみ転送するということにすればセキュリティ上のリスクも最小限にできそうです。

これでローカル PC ( VPN ) → 中継サーバ ( squid ) → マスターノードという通信を確立できました。

中継サーバは HTTP を単に転送していて、 kubectl サーバからはマスターノードが参照できます。また中継サーバの iptables ( firewalld )も少し変更してローカル PC からの HTTP 接続が通るようにしています。

ちなみに Proxy が止まっていたりして接続不能なときは以下のエラーメッセージが出ます。
2021/01/07 20:36:44 http: proxy error: proxyconnect tcp: dial tcp 192.168.111.222:3128: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

宣伝

次世代システム研究室では、最新のテクノロジーを調査・検証しながらインターネットのいろんなアプリケーションの開発を行うアーキテクトを募集しています。募集職種一覧 からご応募をお待ちしています。

  • Twitter
  • Facebook
  • はてなブックマークに追加

グループ研究開発本部の最新情報をTwitterで配信中です。ぜひフォローください。

 
  • AI研究開発室
  • 大阪研究開発グループ

関連記事