‫前回の講義から直接来ていない場合は､
‫前回の講義に戻って､ 適切な Deployment
‫を実行し､ これから見るようなログを取得できるようにしてください｡
‫次に､ Apache Deploymentをバックグラウンドで実行し､ レプリカを2つにスケーリングしたため､
‫2つのポッドを持つことになります｡
‫kubectl
‫get pods をして､ 結果を見ることができるはずです｡
‫もちろん､ あなたのポッド名は､ 末尾に数字やランダムな文字が付くので､
‫私のとは少し違うものになるでしょう｡
‫私がこれを入力しているときはいつでも､
‫最後の2ブロックはDeploymentが表示している内容に基づいて別のものを入力していることを認識してください｡
‫SwarmやDockerそのものと同じように､ いくつかのコマンドがあります｡
‫この場合､
‫コンテナで何が起こっているのかを理解するためのコマンドと､ オーケストレーターがコンテナを使って何をしているのかを理解するためのコマンドの違いです｡
‫1つ目はログです｡
‫2つ目はdescribeです｡
‫Kubernetesには技術的にinspectというコマンドはありませんが､
‫describeはそれ以上のことをします｡
‫まず､ logsコマンドを試してみましょう｡
‫あなたの出力は､ 私のとは少し違うかもしれません｡
‫ログの展開 /my-apache を入力した後の1行目にあることにお気づきでしょうか｡
‫2つのポッドを見つけたと書いてあり､ ポッド名を使って､
‫そこに特定のポッド名をつけています｡
‫それは､ デフォルトのlogコマンドでは､ DockerやSwarmコマンドのように､ 異なるPodをすべて引き出して結合することができないからだ｡
‫あくまでデフォルトでどちらかを引っ張ることになる｡
‫このコースで習った他のログコマンドと同様に､
‫-follow, --tail などのオプションがたくさん用意されています｡
‫これらは､ あらゆるLinuxシステムにおけるロギング・コマンドの共通事項である｡
‫同じコマンドを -- follow とだけ実行すれば､ そのポッドのログに何か新しいものが現れるのを待つことになります｡
‫それから､
‫-tail, 1は､ 最終行だけを返すという意味です｡
‫そうすれば､ ログの巨大なダンプを取得することはありません｡
‫その中からCをコントロールすることができます｡
‫複数のPodを組み合わせたログを見たい場合はどうすればいいのでしょうか？
‫確かにそれはできますね｡ それは､ デフォルトのlogsコマンドでないだけです｡
‫今回は､
‫KubernetesのSelectorと呼ばれる､ 複数のPodに共通するラベルを元にPodを取得するテクニックを使うことになります｡
‫ここで嬉しいのは､ kubectl runコマンドを使うと､
‫これらのPod全てにDeploymentの名前のラベルが自動的に追加されることです｡
‫そのため､ 同じデプロイメント名を使用して､ そのラベルを持つすべてのポッドを選択するために､
‫私のApacheを使用することができます｡
‫なお､ ここではラベルを単純にマッチングさせているだけです｡
‫そのため､
‫このラベルを持つ他のデプロイメントやポッドがある場合､ それらも巻き込まれることになります｡
‫だから､
‫ラベリングやネーミングには気をつけなければならない｡
‫ここでは-lを使ってラベルを指定していますが､
‫これはrunコマンドが適用したラベル､ つまり私のApacheを指定しているのです｡
‫SwarmやDocker自身と同様に､ これらのログコマンドは迅速なトラブルシューティングに非常に便利ですが､
‫完全なログシステムの代替にはなりません｡
‫Kubernetesの場合､ デフォルトではログで引っ張るセレクタ型を使うと､
‫一度に5つのPodまでしか引っ張ることができない｡
‫しかし､ 現実には､ さまざまなノードからこれらのログファイルを取得することは､
‫システムにとって大きな負担となります｡
‫本番環境では､ これらのログをすべて収集し､ 時間をかけて保存し､
‫迅速に検索できるようなサードパーティのログシステムが必要になるでしょう｡
‫これは､ Docker､ Swarm､ Kubernetesなど､ どのコンテナオーケストレーションシステムでも同じことが言えます｡
‫ここで次のコマンドは､ コマンドを記述することになる｡
‫describeコマンドは､ この場合､ ポッドそのものを指定したいところです｡
‫非常に特定のポッドを取得したいのですが､ その場合､ まずそのポッドの名前を知る必要があります｡
‫では､ まずポッドを手に入れましょう｡
‫そして､ それらの名前の1つをコピーして､ describeコマンドに貼り付けることができます｡
‫最初にポッドを入力します｡
‫あのポッドを取り返す｡
‫必ずしもその1ポッドを指定する必要はないんです｡
‫ポッドと言えばすべてのポッドが表示されるので､ ポッドがたくさんある場合は少し危険かもしれませんね｡
‫確かに他のリソースを記述して､ オブジェクトに応じた様々な種類の結果を返すことができます｡
‫ここで強調したかったのは､ これはSwarmやDocker自体のinspectコマンドと同じようなものだろうということです｡
‫でも､
‫JSONで表示するよりも､ 画面上でちょっとだけきれいに表示されるようになります｡
‫結果をスクロールしていくと､ 異なるオブジェクトに関する説明だけでなく､
‫下にあるイベントなども引っ張り出してきて､ そのオブジェクトの現在の実態を素早く把握できるようになっていることに気がつくでしょう｡
‫つまり､ ポッドで画像を取り込む際に問題が発生した場合､
‫「画像を取り込むことができません」というイベントが表示されるのです｡
‫画像名をうっかり間違えてしまった時とか､
‫よくあるやつですね｡
‫これは､ イベントやデバッグログをオンにしなくても､ 迅速なトラブルシューティングを行うために非常に便利な機能です｡
‫わかりました｡ この最後の少しは､
‫KubernetesがSwarmと同様に弾力性があり､
‫下位の抽象化レベルを1つ削除すると､ この場合はポッドを削除すると､ 上位の抽象化レベル､ DeploymentとReplicaSetがそのポッドを再作成することを確認する方法をお見せします｡
‫これは､ Swarmのコンテナやタスクを削除しても､
‫サービスによって再作成されるのと似ていますね｡
‫これを2つのウィンドウで行うのです｡
‫最初のウィンドウでは､ -wを付けてgetを使います｡
‫これで時計コマンドと同じような体験ができそうですね｡
‫このコースで私がwatchコマンドを使って､
‫あらゆるLinuxのコマンドを監視しているのを見たことがあるなら､ それは本質的にバックグラウンドでその物を実行することを意味し､ Linuxでそれを行うことも可能です｡
‫しかし､ そのwatchコマンドは､ すべてのOSで使えるとは限りません｡
‫ここで､
‫kubectl get podsを実行し､
‫-wを追加すると､ 数秒ごとに更新されるようになります｡
‫これで､ 別の端末に行ける｡
‫そのポッドを1つ削除するのです｡
‫最初に をコピーして､ kubectl pod
‫/the name of the
‫pod を使う必要があります｡
‫削除していることがわかると思います｡
‫そして､ この実行中のログを､ 変化しているものを上位に表示させるのです｡
‫また､ ウォッチコマンドは画面をリフレッシュしますが､
‫こちらは進行中の変更を繰り返し表示してくれるので､ ウォッチコマンドよりも少し気に入っています｡
‫下の方にある､
‫kubectl get podsをもう一回実行すると､ 2つに戻っているのがわかると思います｡
‫これもオーケストレーターの自己治癒力のようなものです｡
‫それが､ 持つことの大きな目的の一つです｡
‫最後に､ Docker a Swarmで特定の有害なことをしないように過去に保護されていたかもしれないことを指摘したいと思います｡
‫例えば､ 変更してはいけないものを変更したり削除しようとすると､ 事前に警告が出ることがあります｡
‫Kubernetesは､ 使い方にあまりこだわらないという傾向があります｡
‫つまり､ 先ほどの例で言えば､ ReplicaSetを修正する代わりに､
‫その上のDeploymentを修正するという､
‫やってはいけないことができるのです｡
‫本当はやってはいけないことなのに､ ポッドを変えてしまうのも同じことかもしれません｡
‫その上のオブジェクトを変更する必要があります｡
‫それは､ 誤って間違った順番で削除､ 変更､ 修正することがないように､
‫何をしているのかを具体的に理解する必要があることを強調しているに過ぎません｡
‫このレクチャーからクリーンアップするために､ kubectl delete deployment
‫my-apache を実行することを忘れないでください｡