疎通させろ
問題文
概要
あなたが働く株式会社ICTSCでは、WebサイトをホストするためにKubernetesクラスタを構築しました。しかし、担当者が何らかのミスをし、現在クラスタは正しく動いていない状態です。
また、残念なことに担当者は失踪し、あなたが後任となりました。
正しくWebサイトへリクエストが送れるように、Kubernetesクラスタを直してください。
ネットワークの構成とは以下のようになっています。f35-managerと呼ばれるノードが3つ、f35-workerと呼ばれるノードが3つあり、それぞれ192.168.7.1から192.168.7.6までIPアドレスが割り振られています。それぞれのマシンは同じLANに属しています。 また、f35-lbと呼ばれるロードバランサがあり、kube-apiのロードバランシングを行っています。
またKubernetes内部では、HTTPリクエストへ応答するために、Webサーバーのリソースが作成されています。
他に仕様書などはありません。
初期状態
- 参加者の踏み台サーバーから
curl 192.168.7.1:30000を実行しても応答がない (connection refused)
終了状態
- 参加者の踏み台サーバーから
curl 192.168.7.1:30000を実行するとHTTP応答が帰ってくる
解説
この問題で発生しているしている具体的な問題は2点。
- f35-worker-3のkubelet.serviceがdisable & stopされている点。
- ホスト名が変更されており、かつ使用不可能な文字が含まれている。
ホスト名でアンダーバーが使用されていると、kube-apiserverが起動しません。さらに、ホスト名が初期のものと変更されているので、それも元に戻す必要があります。
まず、各managerノードの/etc/kubernetes/kubelet.yamlやetcd.yamlを見ると、当初のホスト名であるf35-manager-数字が判明するので、managerノードのホスト名を修正できます。
その後、kubectl get nodeコマンドが使えるようになるため、そこでworkerノードのノード名（当初のホスト名）が判明します。そのためworkerノードのホスト名も本来の名前であるf35-worker-数字へ修正できます。
2つ目については、f35-worker-3のkubelet.serviceをstart & enableするだけで構いません。 以上でk8sクラスタが起動するようになります。 また、aliceのdeploymentはnodeselector: f35-worker-3指定があるため、worker-3が起動しないと動かないような設定になっています。
これにについて、報告書に明記していないがおそらく暗黙的にsystemctl start kubeletなど行って居たためにworker-3が起動していたチームは、deployment自体は動いていても満点にしていません。
ただ、「原因の報告」の明記は問題文中で指定されていなかったため、結果worker-3でpodが動くような指示(systemctl start, systemctl restart, systemctl disable && reboot、nodeselectorの削除等)を報告書に明記したチームに関しては満点にしました。
最後に、kubectl get serviceを実行すると、Aliceという名前のdeploymentがNodePort 30000ポートでlistenしていることがわかる。 試しにcurlしてみるとリクエストが通るので問題が解決できたことになります。
所感
f35-worker-3のkubelet.serviceがdisable & stopされている点。という問題が結構なチームが気づかれず、作問者としては残念でした。
採点のポイントとしては、 「問題解決の手順を報告書に書いているかどうか」 と 「初期状態のマシンで、報告書に書いてある作業を同じように実行すれば終了状態を満たした状態ができるかどうか」 「報告書に書いてあるコマンドや編集作業を問題サーバーでも同じように実行しているかどうか」 の3点で採点を行いました。 ちなみに、今回満点を取ったのは3チームです。
最後に今回の珍解答ですが、k8sクラスタを解体しゼロから作り直しているチームが複数見受けられました。 正直、内容を見る限りとても頑張っていて点数を上げたかったのはやまやまなのですが、解体前に内部で動いているリソースをエクスポートし、構築後applyができていなかった（終了状態を満たしていなかった）ため、0点とさせていただきました。
以上、ありがとうございました。