Kubernetesからの、MetalLB、Nginx ingress controllerのブラックボックス感が半端ないということで、ログを観るしかないかな～と思っていたところ、
⇧ 上記サイト様により、「stern」なるデバッグツールが存在するらしいことを知る。
ちょうど、前前回、
⇧ MetalLBとNginx ingress controllerとの絡みで躓いていたので、ログから何か分からんもんか？と思っていたところでした。
というわけで、今回は、「stren」というデバッグツールにトライ。
「stren」をインストール
さっそく、https://github.com/wercker/stern にアクセス。
- バイナリからのインストール
- ソースからインストール
- goでインストールため、依存関係の解決にGovendor（The Vendor Tool for Go）が必要らしい。goも必要なのかな？
今回は、バイナリからインストールということで。
ビルド済みのバイナリを以下からダウンロードしてPATHを通します。
最初のアプリケーションを動かしてみる - Cloud Native Developers JP - ハンズオンチュートリアル
sternはデフォルトでkubectlの設定情報を利用して動作しますので、kubectlが利用できていれば、追加の設定作業は必要ありません。
最初のアプリケーションを動かしてみる - Cloud Native Developers JP - ハンズオンチュートリアル
⇧ 上記サイト様によりますと、バイナリのインストール後、環境変数にパスを追加する必要があるようです。
というか、そういう説明を「stern」の「Installation」 でちゃんと説明してくれって話ですよ、というボヤキは置いといて。
https://github.com/wercker/stern/releases にアクセスして、「stern_windows_amd64.exe」のリンクのアドレスをコピーし、
適当な、テキストエディターなんかで、
curl -Lo [保存先のパス（ファイル名まで指定）] https://github.com/wercker/stern/releases/download/1.8.0/stern_windows_amd64.exe
と整えて、コマンドプロンプトで実行します。（curlをインストールしてない場合は、curlをインストールするか、直接リンクをクリックでダウンロードします。）
とりあえず、sternが、kubernetesで使えるコマンドってことだったんで、kubectlコマンドをインストールしたときと同じディレクトリに保存しました。
システム環境変数の「Path」を「編集」で、
パスを追加してない場合は追加します。自分は、すでに、「kubectl」のバイナリをインストールしたときにパスを追加済みでした。
バージョン確認。
stern -v
⇧ sternがインストールできたようです。
実際にsternを利用してみる
とりあえず、kubernetes cluster環境の整った仮想マシンを起動。
一応、minikube内臓のdockerも動くように。
では、sternを実行。
stern $POD_NAME
⇧ 待てど暮せど、処理が進まず...
pod自体は存在しますけど？
どうやら、Namespaceを指定せんとマズイらしい。
stern [Pod名（ワイルドカードの指定もOK）] --namespace [Kubernetesにおけるネームスペース名]
Ctrl + C でログの閲覧を終了できるようです。
で、MetalLBのBGPモードで使われているであろうと思われる、BGP（Border Gateway Protocol）の説明が、
BGPはTCPポート179番を利用して通信を行います。BGPルータはピアを確立するために、メッセージと呼ばれる形式で機能情報を交換します。メッセージはBGPの状態により数種類存在します。ピアが確立した後は、経路情報を伝達するためのメッセージを定期的に交換し、お互いの持つ経路情報を保持、更新し続けます。
BGPプロトコルで交わされるメッセージと、メッセージが利用するパス属性
OPENメッセージ
OPENメッセージはTCPセッションの確立後、最初に交換されるメッセージです。OPENメッセージはお互いのAS番号やピアの認証を行い、拡張機能などについて情報の交換を行います。ピアの確立に問題が無ければ、後述のKEEPALIVEメッセージやUPDATEメッセージの交換に移ります。
KEEPALIVEメッセージ
KEEPALIVEメッセージは、ピアが確立されていることを確認するために定期的に交換するメッセージです。KEEPALIVEメッセージを交換する頻度は、OPENメッセージのホールドタイマの値から設定されます。一般的にKEEPALIVEメッセージはホールドタイマの1/3の間隔で交換されます。ホールドタイマの時間が過ぎてもKEEPALIVEメッセージやUPDATEメッセージが交換されないと、ピアがダウンしたと判断されます。
UPDATEメッセージ
UPDATEメッセージは実際の経路情報を伝達するメッセージです。UPDATEメッセージには新規にアナウンスする経路情報と削除する経路情報のリストが格納されています。UPDATEメッセージの中には経路情報ごとにパス属性という属性情報が存在し、経路制御に利用されます。パス属性の詳細については後述します。
NOTIFICATIONメッセージ
NOTIFICATIONメッセージはピアに対し、ピアの継続不可能なエラーが発生した場合に送信されます。NOTIFICATIONメッセージを送信した送信者側は、NOTIFICATIONメッセージを送信後、TCPのセッションを切断します。
となっていて、ログからも、Minkubeとテスト用のBGP Router の間の接続は問題なくできていそうです。
ちなみに、
⇧ 上記サイト様が、「SDN（Software Defined Network）」の流れについて詳しいのですが、
⇧ 上記サイト様によりますと、SDNは、ネットワークなどのハードウェアで構築されたインフラ周りなどの管理をソフトウェアで実現しようという考え方らしいです。
昨今、「SDx（Software Defined Internet Exchange ）」 という考え方が急速に広まりつつあるようです。
⇧ 上記サイト様によりますと、SDxには、
- SDN（Software Defined Network）
- SDS（Software Defined Storage）
など、 いろいろあるようです。xの部分が「何でも」って言うことみたいですね。
JavaScriptのフレームワークであるAngularJSなんかで「MVW（Model-View-Whatever）」というアーキテクトの概念がありましたが、それの「Whatever」の感覚に近い感じですかね？
⇧ 上記サイト様によりますと、SDxはまだ成熟しているとは言い難いようです。
脱線いたしましたが、とりあえず、Minikubeとテスト用のBGP Routerのネットワーク接続は確立されているらしいと。インフラ周りはよく分からんとです...。
引き続き、調査して参りますかね。
2018年9月2日：追記 ↓ ここから
どうやら、コンテナ内で、httpd（Apacheサーバ）が起動していなかったようです。
コンテナimageを鋭意再作成中ですが、まだ上手くいってないです。
2018年9月2日：追記 ↑ ここまで
今回はこのへんで。
