SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

Kubernetes のコンテキストの切り替えとかいろいろ

leave a comment

Docker for Win/MacのKubernetes統合が正式版に。Stable Channelでリリース開始 で記事が公開されていますが、Docker for Windows / Mac の安定版 (Stable) で Kubernetes (k8s) が正式にサポートされました。
私の特価領域は SQL Server のデータベースエンジンではあるのですが、SQL Server にとっても k8s は、関わりのあるインフラスキルとなりつつあります。
SQL Server 2017 で、Docker のサポートが追加されています。
Microsoft SQL Server のテクニカル サポート ポリシー にサポートポリシーが記載されていますが、コンテナーのテクノロジーについては、OpenShift / Kubernetes もサポート対象と明記されています。
Kubernetes のオートヒーリング機能を使用した SQL Server の導入方法については Kubernetes での高可用性 SQL Server のコンテナーを構成します。 で情報が公開されています。
また、現時点では、すぐに自分で試せるものではないですが、SQL Town Hall: Always On Availability Groups on Kubernetes and OpenShift で AlwaysOn 可用性グループを Kubernetes上で実行する構成というものについても計画があることがアナウンスされており、可用性を OS のクラスターテクノロジーではなく、コンテナーのオーケストレーションツールで担保するというような選択肢を手に入れることができるようになります。
ということで、最近 minikubeAzure Kubernetes Service (AKS) で Kubernetes の勉強を始めているのですが、そのなかで、「複数のクラスターを管理するのってどうするんだろう」ということが気になったので、勉強した内容をまとめてみたいと思います。
今回は次のような構成を準備しています。

  • Windows 10 + Docker for Windows + Kubernetes
  • Ubuntu 16.04.5 + Kubernetes

この環境で、Ubuntu の Kubernetes を kubectl で操作するための流れを見てみようかと。
証明書については、Ubuntu のものをそのまま流用して使用しているので、新しい証明書を作って~というような流れまでは調べられていません…。
詳細については、Configure Access to Multiple Clusters を参照してください。
(これを見ながら勉強した内容が、本投稿ですので)

Windows 10 上の kubectl で使用される情報を確認する

まずは、Windows 10 でどのようなクラスターとコンテキスト (接続に使用する情報) を持っているかを確認してみます。

  • クラスターの取得 : kubectl config get-clusters
  • コンテキストの取得 : kubectl config get-contexts

「kubectl config get-clusters」を実行すると次のような情報が取得できます。
Kubernetes のクラスターとしては、「docker-for-desktop-cluster」というクラスターを認識していることが確認できますね。
image
「kubectl config get-contexts」を実行した場合は、次のような情報が取得できます。
先ほど確認した「docker-for-desktop-cluster」というクラスターを走査するためのコンテキストが現在選択されていることが確認できますね。
image
この情報から、自分が操作しようとしているクラスターがどこなのかを確認することができます。
これらの情報はどの情報を参照しているかというと「kubeconfig」と言われることがある、構成ファイルの情報を読み取っています。
どのような情報があるかについては、次のコマンドで確認することができます。

  • 構成の取得 : kubectl config view
  • 現在のコンテキストの構成の情報のみ取得 : kubectl config view –minify

minikube や Docker for Windows の Kubernetes をインストールした直後は、コンテキストが一つしかないはずなのでどちらを実行しても、結果話変わりませんが、次のような情報が取得できます。
構成のような内容となっているかを確認することができますね。
image
 
さて、ここまで見た情報ですが「どこにある情報」を見ているかというと、デフォルトの状態では「%USERPROFILE%.kube\config」のファイルの内容がベースになっており、kubectl config コマンドはこのファイルの内容が操作されているため Kubernetes のクラスターが動作しているかどうかに関係なく、構成ファイルの情報を見ることができるようになっています。
(kubectl config で情報が取れてもクラスターが動いていない状態というのはあり得ます)

Windows 10 から Ubuntu の Kubernetes を kubectl で操作する

ここからが本題となります。
ローカルの「どのファイル」が使用されているかはわかりましたので、次はこの環境から別の環境の Kubernetes を操作するための準備をしていきます。
現在、Windows 10 の環境については、ローカルの Docker for Windows で構築された、Kubernetes を操作するための設定のみが行われていますので、ここに Ubuntu の Kubernetes を操作することができるようにします。
最初に Ubuntu 上にある「kubectl で使用される config」を Windows 側にコピーします。
Ubuntu 側で使用されているファイルについては「/etc/kubernetes/admin.conf」または、kubectl を実行できるユーザーの「$HOME/.kube/config」となるかと思いますので、このファイルを Windows にコピーします。
今回は、Ubuntu からコピーしたファイルは「config-k8s」としてコピーしています。
Windows で kubectl を使用できるユーザーの「.kube」ディレクトリについては次のようなファイルが格納された状態となります。

  • config : Docker for Windows の Kubernetes 有効化時に作成されたファイル
  • config-k8s : Ubuntu 上に構築された Kubernetes からコピーしたファイル

image
この状態で「kubectl config get-contexts」を実行しても、先ほど認識していた Docker for Windows のクラスターしか認識されていません。
image
先ほどコピーしてきた構成ファイルを使うための方法ですが、いくつかの方法があります。
「–kubeconfig」オプションを利用する方法
最初は「–kubeconfig」というオプションを各コマンドで使うものです。
それでは、「kubectl –kubeconfig config-k8s config get-contexts」という形で、「–kubeconfig」にファイル名を指定してみます。
今、ロケーションとしては「C:\」にいる状態なのですが、この状態でコマンドを実行しても、情報が取れていないですね。
image
単純に「–kubeconfig」を実行した場合、カレントディレクトリをファイルの走査の起点とするようで、カレントディレクトリに kubeconfig のファイルがないと内容を読み取ることができません。
先ほどはユーザープロファイルの「.kube」にコピーしましたので、このファイルを「kubectl –kubeconfig “${ENV:USERPROFILE}.kube\config-k8s” config get-contexts」というような形で、フルパスで指定してみます。
image
コピーしてきた kubeconfig の内容が使用され、カレントがローカルの Kubernetes の情報ではなく、Ubuntu 上の Kubernetes となっていますね。
「kubectl –kubeconfig “${ENV:USERPROFILE}.kube\config-k8s” get? all」で Ubuntu 上の Kubernetes の情報を取得して見たものが下の画像になるのですが、情報が取れていることが確認できますね。
image
コマンドに「–kubeconfig」を設定することで、使用する kubeconfig を制御することができます。
この方法ですと、コマンドごとにオプションを設定する必要があり、これが手間な場合は、次に紹介する方法を使用して、オプションを省略することもできます。
 
KUBECONFIG 環境変数を使用する方法
こちらの方法は「環境変数に複数の kubeconfig を指定し、複数のファイルの内容をまとめて管理する」ものとなります。
「$ENV:KUBECONFIG=”${ENV:USERPROFILE}.kube\config;${ENV:USERPROFILE}.kube\config-k8s”」というような形で、環境変数「KUBECONFIG」に複数の構成ファイルを指定します。
(PowerShell で実行したものになりますので、コマンドプロンプトの場合は SET / ユーザープロファイルを %USERPROFILE% に置き換えて下さい)
環境変数を設定した後に「kubectl config get-contexts」を実行してみると、二つの構成ファイルの内容がまとめて読み込まれていることが確認できますね。
image
環境変数に追加した順番に読まれているようで、今回は最初に読みこまれた「config」の Docker for Windows の方がカレントのコンテキスト (* がついている) となっていますね。
この状態で kubectl コマンドを実行した場合、カレントのクラスターに対しての操作となりますので、Ubuntu の Kubernetes である「kubernetes」の CLUSTER をカレントにしたい場合は次のように「kubectl config use-context kubernetes-admin@kubernetes」 を実行します。
「kubectl config use-context」は複数のコンテキストがある場合に、どのコンテキストをカレントにするかを切り替えるものになります。
image
「*」が表示されている行が切り替わっていることが確認できますね。
これで、カレントのコンテキストが変更されましたので、kubectl コマンドは選択されているクラスターに対して実行されることになります。
先ほどとは異なり「–kubeconfig」を省略し、「kubectl get all」というような形で、実行した場合、現在使用されているコンテキストが設定しているクラスターである Ubuntu 側の Kubernetes の情報が取得されていることが確認できますね。
image
実運用では複数クラスターを手元で管理する機会もあると思うのですが、その際にどのような方法を使えばよいのかを勉強した内容を簡単ではありますが、まとめてみました。

Share

Written by Masayuki.Ozawa

7月 28th, 2018 at 10:50 pm

Posted in kubernetes

Tagged with

Leave a Reply