Kubernetes and Cloud Native Associate 無料問題 5 / 10 ・ 分野2: Container Orchestration
Namespace のすべての Pod への受信を拒否する NetworkPolicy を作ったが、ほかの Pod からの接続がまだ通る。公式ドキュメントから考えられる原因はどれか。
- クラスタのネットワークプラグインが NetworkPolicy を実装していない
- 新しいポリシーは評価の順が後になり、先にある許可のポリシーが勝つ
- NetworkPolicy は Service の名前で対象を選ぶので、Pod への直接の接続は対象外
- NetworkPolicy は、クラスタ全体の既定のポリシーとして置いたときに効く
正解と解説を見る
正解: A
正解の理由
Network Policies のページは、ネットワークポリシーはネットワークプラグインが実装するもので、使うには NetworkPolicy に対応したネットワークの実装が必要であり、実装するコントローラが無いまま NetworkPolicy のリソースを作っても効果は無いと書いている。ネットワークモデルのページも、NetworkPolicy に対応しない簡単な実装や、対応を切った構成では、API は存在しても効果は無いと書いている。
違う選択肢
「新しいポリシーは評価の順が後になり、先にある許可のポリシーが勝つ」… ページは、ネットワークポリシーは互いに衝突せず足し合わされるもので、評価の順は結果に影響しないと書いている。
「NetworkPolicy は、クラスタ全体の既定のポリシーとして置いたときに効く」… ページは、すべての Namespace や Pod に効く既定のポリシーは NetworkPolicy の API ではできないことの1つに挙げている。既定の拒否は Namespace ごとに、その Namespace の全 Pod を選ぶポリシーとして作る。
「NetworkPolicy は Service の名前で対象を選ぶので、Pod への直接の接続は対象外」… ページは、Service を名前で対象にすることは NetworkPolicy ではできず、ラベルで Pod や Namespace を選ぶと書いている。
押さえどころ
NetworkPolicy は API としては常にあるので、作成が成功しても効いているとは限らない。効き目はネットワークプラグインが持つ。ポリシーは足し合わせで、順序や優先度の考え方は無い。