‫このYAMLには2つのメタデータがあります｡
‫おそらく､ 例の中で見て､ ラベルと注釈は本当は何のためにあるのだろうと考えたことがあるでしょう｡
‫おそらく､ その意味を理解していなかったのでしょう｡
‫Kubernetesの重要な構成要素であり､ 物事が相互に接続する方法です｡
‫スウォームよりもずっとね｡
‫1つ目はラベルです｡ ラベルはファイルのルートでメタデータキーの下に入るので､
‫そこではオプションです｡
‫置かなくても良いのですが､
‫ラベルの見出しの下にキーバリュー､ つまりキーバリューのリストがあります｡
‫それは､ 複数の理由があります｡
‫必ずしも必要なものではありませんが､ オブジェクトの選択､
‫グループ化､ さらには後でフィルタリングを行う際に必要となる場合があります｡
‫これは､ オブジェクトやリソースを説明するものであれば何でもよい｡
‫値が単に真か偽であるキー・バリュー・ペアにすることができる｡
‫キーは何でもいいんです｡
‫各オブジェクトに複数のキーを指定することはできないので､ 同じオブジェクトのYAMLに､
‫たとえばappというキー名を持つキーを2つ並べることはできません｡
‫これらは､
‫本当に対象物を表現するために使われます｡ 作成するこれらのリソースは､ それぞれ異なる特性を持ちます｡
‫prod､ dev､ testといった環境かもしれません｡
‫dmzのような場所か､ backendかfrontendか､
‫かもしれません｡ アプリ名かもしれないし､ クライアントサイトをホスティングしている場合などはクライアント名かもしれません｡
‫好きなようにすればいいし､
‫基準もあまりない｡
‫ここのリソースに記載されているKubernetesのドキュメントには､
‫いくつかの例が記載されていますが､ それはあくまで例です｡
‫この業界には基準がないんです｡
‫このことをどう表現するかは､ あなたのチーム､
‫あなたの会社次第です｡
‫また､ アノテーションもあります｡ 陰と陽のようなものですね｡
‫ラベルはとてもシンプルです｡
‫サイズや入れられる文字が非常に限定されているのです｡
‫リソースを説明するためのものです｡
‫アノテーションの場合は､ より複雑なデータや多値のデータなどを対象とします｡
‫アノテーションは通常､ Kubernetesと会話し､ そこからデータを取得できるようなカスタム物をKubernetesに追加するときに使用されるのを見かけます｡
‫アノテーションは､ プロキシやイングレスがしばしば異なるアノテーションの中に異なる設定を保存するように､
‫設定データを保存するためにあります｡
‫ですから､ それらは必ずしも描写のためにあるのではなく､
‫むしろコンフィギュレーションのためにあるのです｡
‫ラベルの話に少し戻ります｡ Kubernetesでこれらのものがどのように機能するかを理解するための鍵は､
‫ラベル以外にもたくさんあるからです｡
‫まず､ コマンドラインからラベルに限定して簡単なフィルタリングを行うことができることです｡
‫ポッドを取得して､ このラベルのついたポッドだけを表示するようにすればいいのです｡
‫そこでカンマを使えば､ 複数のラベルを追加することも可能です｡
‫実際､ これには構文のレベルがあり､ さまざまなタイプの構文､
‫さまざまなorやandを行うことができるのです｡
‫本当に､ REGEXを学ぶようなものなので､
‫すべてを教えたくはないのですが｡
‫一度やっただけでは身につかないものなのです｡
‫必要な時にこそ､ 本当に理解できるようになるのです｡
‫Kubernetesのドキュメントは本当に素晴らしいです｡
‫ラベルを必要とするさまざまな経路を案内してくれるリンクが､
‫資料の中にいくつかあります｡
‫率直に言って､ 問題を解決するために必要だとわかるまで､
‫それを学ぶ必要はないでしょう｡
‫コマンドを適用するのにも使えます｡
‫1つの大きなYAMLファイルにたくさんのものがあって､
‫そのYAMLファイルの特定の部分のみを適用したい場合｡
‫私はあまりやりませんが､ 特定のラベルに対してYAMLに入れた変更や情報のみを適用するように制限することも可能です｡
‫もちろん､ 今回も同じ構文を入れることができます｡
‫ラベルは1枚でいいんです｡
‫カンマを入れたり､ 複数のラベルや値をそこに持たせることができます｡
‫それはあなた次第です｡
‫もうひとつ､ Kubernetesの仕組みに重要なラベルの役割があります｡
‫それは､ 他のリソースと対話する､ あるいはそれに接続する､
‫あるいは関連する特定のリソースが存在するということに尽きます｡
‫どんな言い方をしようとも｡ 良い例としては､ サービスがどのポッドにトラフィックを送るかを知る必要があることです｡
‫なぜわかるのか不思議に思うかもしれません｡
‫つまり､ kubectl service Commandを実行してデプロイメントを指定する場合､
‫そのデプロイメントを特定するために一体何を使っているのか､
‫ということです｡
‫まあ､ CLIでは､ 実際にデプロイメント・オブジェクトを指していると思うでしょう｡
‫しかし､ 実際には､ サービスはデプロイメント自体ではなく､ ポッドと話をする必要があります｡
‫ラベルセレクタというものを使っているのです｡
‫これは､ ポッドの上位抽象レベルであるさまざまなリソースに共通することです｡
‫彼らがポッドと関係を持つため､ あるいはどのポッドが自分のものかを知るために､
‫ラベルセレクタを使用します｡ この数回の講義で使用したレポの中のYAMLを見ればわかると思います｡
‫アプリ内を見ると yml を見ると､ これまでずっと､ この中で説明していないことがいくつかあることに気がつくでしょう｡
‫まず､
‫一番上のサービスの部分ですが､ スペックの下にセレクタがあります｡
‫それは､ そこにあるべきものです｡
‫トラフィックを誘導する必要のあるポッドのラベルのキーと値を伝えているのです｡
‫それは単純なマッチングに過ぎない｡
‫それを使ってポッドを探す必要があるのです｡
‫そして､ その下のデプロイメントでは､ 私たちの仕様が独自のセレクタ､
‫matchLabels､ app､ app-nginxを持っていることがわかります｡
‫そこで起こっているのは､ これらのオブジェクトの両方が､ そのマッチングに基づいてポッドを選択しているということです｡
‫つまり､ 仕様の下のテンプレートで､ ポッドをテンプレート化し､
‫そのラベルを付けて､ リソースがポッドを見つけられるようにする必要があるのです｡
‫Kubernetesの最新バージョンでは､ 少なくとも1回のデプロイでは､
‫これらを同期させる必要があるのが良い点です｡
‫セレクタのマッチラベルがテンプレートのメタデータラベルと一致しない場合､
‫デプロイに失敗します｡
‫間違ってやってしまうのを防ぐためにあるんです｡
‫それらの部品が入っていることを期待することになります｡
‫古いバージョンでは､ デフォルトで自動的に生成する方法がありましたので､
‫そのようなものは省くことができました｡
‫今はそれをやめて､
‫無理やりこれを入れているんです｡ 特に､ このラベルセレクターがいかに重要であるかということですね｡
‫技術的には､
‫Swarmに戻ると､ Swarmは､ スタックとサービス､ スタックとそのボリュームなどを一致させるラベルを持っていて､
‫これをそのまま少しやっています｡
‫私たちはそれをコントロールすることはできませんし､ インターフェイスでもあまり見かけません｡
‫Swarmでは､
‫バックグラウンドで行われているようなものです｡
‫しかし､ それは非常に限定的なことでもあるのです｡
‫その場その場で変えることはできない｡
‫また､ カスタマイズして独自のセットアップを行うこともできません｡
‫ここで､ セレクタを変更すれば､ 1つのサービスを複数のデプロイメントに対応させることができます｡
‫セレクタは､ リソース同士を結びつけるだけではありません｡
‫また､ その行き先をコントロールすることでもあります｡
‫ノード上では､ ラベルとセレクタを使って､ ノードの移動先を制御することができます｡
‫テイントやトレレーションと呼ばれるものを使って､
‫さらにカスタマイズすることもできます｡
‫この手のものは､ すぐにカスタム化､
‫高度化します｡ 全部一緒にやると､ ちょっと毛むくじゃらでおかしくなってしまう｡
‫ぜひ､ ゆっくり付き合っていくことをおすすめします｡
‫シンプルなアウトオブボックスに徹する｡
‫テイントとトレランスは､ 本当にそれらを調べる必要があるまで､
‫避けてください｡
‫わかりました｡ このセクション全体のために､ 掃除をしましょう｡
‫もしクラスタのデフォルトのネームスペースで何か動いていたら､ kubectl
‫get all を実行して､ Kubernetes API 以外のものが表示されたら､
‫先に進み､ それらのリソースをすべて削除してください｡
‫それは必要ないでしょう｡