‫最初のクラスタ､ おそらく最初の数クラスタでは､
‫このネームスペースとコンテキストの概念についてあまり気にする必要はないでしょう｡
‫しかし､ 万が一のために､ その存在を知っておく必要があるものです｡
‫名前空間は､ 基本的に単一のクラスタ内の仮想クラスタ､
‫または仮想ビューです｡
‫コマンドを入力するときに特定のものしか見えないように､ コマンドの表示をフィルタリングするだけでなく､
‫適切なネットワークポリシープラグインを使えば､ ネットワークの制御も可能なのです｡
‫これは､ Swarmとは少し違います｡ Swarmは､ すぐに使えるように､
‫さまざまなオーバーレイネットワークを作り､ すべてが基本的にプライベートになっています｡
‫Kubernetesでは､ ネットワークとアプリの制御､ アプリのプライバシー､
‫アプリが見ることができるもの､ アクセスできるもの､ そこで物理的に制御されるものは､
‫ネットワーク・プラグインに本当に依存しています｡
‫名前空間自体はDockerの名前空間とは無関係で､ 聞いたことがあるかもしれませんが､
‫これは本当にLinuxのサブシステムの一部で､ コンテナがどのように動作するかのようなものです｡
‫それとこれとは関係ないんですけどね｡
‫これは単にKubernetesが､ 「クラスタの中でたくさんのことが起こっているかもしれないので､
‫小さなミニクラスタを作って､ コンテキストで名前空間を設定し､
‫コンテキストを変更することで自分のビューを表示する機会を提供します」と言っているだけです｡
‫見るものを変えることができる｡
‫それから､ 名前空間は､ コマンドをフィルタリングするための異なるセグメントであり､
‫潜在的にネットワークでもある｡
‫私のシステムでは､
‫デスクトップ上でkubectl get namespacesを実行すると､ 4つ表示されます｡
‫これが､
‫ある意味､ 常識はずれの標準的な姿なのです｡
‫デフォルトは今までのものです｡
‫これは､ アプリのデフォルトの名前空間のために作られたものです｡
‫kubectl
‫get allで表示されるのは､ Kubernetes
‫APIエンドポイントそのものだけですね｡
‫アプリを追加するまでは､ 何も見えていなかったんです｡
‫技術的にはバックグラウンドでいろいろなものが動いているわけですよね｡
‫それが､ kubectl get all --all
‫namespacesです｡
‫そのコマンドでKubernetes自体の中で動いているAPIコンテナや何やらを全て見ることができます｡
‫すべての名前空間を一度に見ると､
‫システムものも含めて全部出てくるんです｡
‫これは､ クラスタ自体を実行するためにすべてを独自のポッドに置くminikubeでの表示です｡
‫いろいろあるんですよ｡
‫実感としては､ 普通にKubernetesを使っていると､
‫コマンドラインはデフォルトのネームスペースにフォーカスしてしまうんです｡
‫APIエンドポイント以外では､ 本当に自分のアプリしか表示されないのです｡
‫それはそれで､ いいんじゃないですか？ なぜなら､ アップグレードや変更が必要なとき､
‫あるいは問題が発生したとき以外は､ そのようなものを見る必要がないからです｡
‫コマンドを実行するときのビューを設定するには､
‫コンテキストが重要です｡
‫kubectlはいろいろなことをやってくれるんですね｡
‫異なるクラスタに接続することができます｡
‫クラスタとの通信に使用する認証やユーザーを変更したり､
‫名前空間を変更したりすることができます｡
‫つまり､ コンテキストには3つの部分があるのです｡
‫つまり､ クラスタ､ 認証､ またはユーザー､
‫そして表示したい名前空間です｡
‫これらはすべて､ デフォルトでは.NET Frameworkの中のファイルで定義されています｡
‫ホームディレクトリの
‫kube ディレクトリ｡
‫その中にconfigというファイルがあり､ 基本的にはこれら3つのパーツをすべてYAMLファイルにしたものになります｡
‫そこには複数のエントリーがあり､ 好きなように編集することができます｡
‫さまざまなクラスタがあり､ それらと対話するための証明書と正しい認証さえあれば､
‫そのファイルにすべてのものを入れることができますし､ それは秘密にしておきたいものです｡
‫クラスタと通信するための認証キーが格納されていることが多いので､
‫あまり共有したくはないでしょう｡
‫kubectl
‫configコマンドでget contextsというサブコマンドを使えば､ 基本的にそのファイルの出力を見ることができます（複数形です）｡
‫生で捨てるのではなく､
‫実際にその中に入っているものをちょっと素敵なリストで見ることができるんです｡
‫私の場合､ ローカルマシンに標準のDocker Desktopを入れています｡
‫このエントリは､
‫Docker Desktopの過去数回のエディションで2回入っていますが､ これは名前が変わったためで､
‫互換性を保つために両方入れているようなものです｡
‫そして､ ローカルのminikubeと､ Ubuntuサーバー上で動作するmicro
‫K8sのリモートインスタンスを持っています｡
‫ですから､ もし私が他の多くのサーバーを管理していたとしても､ 必ずしもそれらのマシンに常にsshで入りたいとは思わないことは想像できますよね｡
‫私は本当に､
‫自分のローカルマシンに座って､ リモートAPIと話をしたいだけなのです｡
‫kubectl configコマンドは､ 設定したオプションで使用することができます｡
‫そこのヘルプは絶対にチェックしたほうがいい｡
‫しかし､ それぞれにデフォルトを設定するためのオプションが設定されているので､
‫ユーザーを別の認証に変更できる可能性があります｡
‫つまり､
‫Kubernetesが実行できるコマンドのサブセットではなく､ 神の権限を持つことができるのです｡
‫あるいは､
‫話し相手のクラスタを変えるとか｡
‫Googleで調べれば､ どのコンテキストを使用しているかをシェルで確認できるコマンドラインプラグインもあるようです｡
‫これは､ さまざまなクラスタを管理することになったときに便利な機能です｡
‫知りたいのは､
‫「今､ 私はどちらと話をしているのか」ということですよね｡ 実際に設定することも可能で､ 取得プロンプトがどの支店にいるか教えてくれるようなものです｡
‫これらは､
‫プロンプトで､ どのようなコンテキストを持っているかを教えてくれます｡