複数のインターフェイスポッド
複数の仮想ネットワークを作成すると、次のような pod’s yaml ファイルを使用して、任意の接続を pod にアタッチできます (プラグまたは挿入することもできます)。
またはその他の有効な形式:
’おそらく、名前空間内の pod はローカル名前空間で定義されたネットワークだけではなく、完全にスコープが付いた名前を使用して他の名前空間で作成されたネットワークを参照することにも気付きます。これは非常に便利です。同じネットワークを、それを必要とするすべての名前空間で繰り返し複製する必要はありません。一度定義してから、他の場所で参照することができます。
私’たちは基本的な理論について説明し、さまざまなテンプレート’について解説してきました。実際の例を見てみましょう。まず’、仮想ネットワークオブジェクトを検証し、次に、ポッドを作成して2つの仮想ネットワークを接続することによって、2つの仮想ネットワークを作成してみましょう。ここ’では、ポッドインターフェイスと、同じ仮想ネットワークを共有する他のポッドとの接続を検証します。
2つの仮想ネットワークの YAML ファイル (vn-1 および vn) は次のとおりです。
ここで、仮想ネットワークを作成します。
$ kubectl apply -f vn-left-1.yaml networkattachmentdefinition.k8s.cn i.cncf.io/vn-left-1 created $ kubectl apply -f vn-right-1.yaml networkattachmentdefinition.k8s.cn i.cncf.io/vn-right-1 created
仮想ネットワークを検証します。
$ kubectl get network-attachment-
definitions.k8s.cni.cncf.io NAME
AGE
vn-left-1 3s
vn-right-1 10s
$ kubectl get network-attachment-
definitions.k8s.cni.cncf.io vn-left-1 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind:
NetworkAttachment
Definition metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata
":{"annotations":{"opencontrail.org/cidr":"10.10.10.0/24","op
encontrail.org/ip_fabric_forwarding":"false"},"name":"vn-left-1","namespace":"ns-user-
1"},"spec":{"config":"{ \"cniVersion\": \"0.3.0\", \"type\":
\"contrail-k8s-cni\" }"}} opencontrail.org/cidr:
10.10.10.0/24
opencontrail.org/ip_fabric_
forwarding: "false"
creationTimestamp: 2019-06-13T14:17:42Z
generation: 1
name: vn-left-1
namespace: ns-user-1
resourceVersion: "777874"
selfLink: /apis/k8s.cni.cncf.io/v1/namespaces/ns-user-
1/network-attachment-definitions/vn-left-1 uid:
01f167ad-8de6-11e9-bbbf-0050569e6cfc
spec:
config: '{ "cniVersion": "0.3.0", "type": "contrail-k8s-cni" }'仮想ネットワークが予想どおりに作成されます。これは非常に興味深いことではありませんが、Contrail UI にログインすると、次の画面キャプチャで予期しない問題が発生します。Figure 1。
適切なプロジェクトが選択されていることを確認してください。この場合は、k8s がデフォルトです。
そして、どの’ような仮想ネットワークも、vn-1 または vn-1 の正確な名前で UI に含まれていないことがわかっています。代わりに、k8s vn-left-1-1u ネットワークと k8s-vn 右ポッドネットワークという2つの仮想ネットワークがあります。
ここには問題はありません。ここでは、Kubernetes から仮想ネットワークを作成するたびに Contrail、Kubernetes のクラスター名 (デフォルト k8s) が、ネットワーク YAML ファイルに指定した仮想ネットワーク名にプレフィックスとして自動的に追加されます。最後にサフィックスが付いています。これは理にかなっていますが、仮想ネットワークはさまざまな方法で作成でき、これらのキーワードが名前に’埋め込まれていることがわかっているので、仮想ネットワークの作成方法 (Kubernetes から、または UI から手動で) をわかりやすくし、どのように使用するかを簡単に知ることができるようになります。また、複数の Kubernetes クラスターで作業している場合は、仮想ネットワーク名の競合を回避することもできます。
次の例は、複数の仮想ネットワークを備えた pod の YAML ファイルです。
Pod 注釈のメタデータで、2つの仮想ネットワークを挿入します。vn-1、vn-右-1。ここで、ブート時に pod が持つインターフェースの数を推測してみましょう。ファイルに指定されたものであるため、2つのことが考えられるかもしれません。ポッド’を作成して検証しましょう。
$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
webserver-mv 1/1 Running 0 20s 10.47.255.238 cent222 <none>
$ kubectl describe
pod webserver-mv
Name: webserver-mv
Namespace: ns-user-1
Priority: 0
PriorityClassName: <none>
Node: cent222/10.85.188.20
Start Time: Wed, 26 Jun 2019 12:51:30 -0400
Labels: app=webserver-mv
Annotations: k8s.v1.cni.cncf.io/network-status: [
{
"ips": "10.10.10.250",
"mac": "02:87:cf:6c:9a:98",
"name": "vn-left-1"
},
{
"ips": "10.47.255.238",
"mac": "02:87:98:cc:4e:98",
"name": "cluster-wide-default"
},
{
"ips": "20.20.20.1",
"mac": "02:87:f9:f9:88:98",
"name": "vn-right-1"
}
]
k8s.v1.cni.cncf.io/networks: [
{ "name": "vn-left-1" }, { "name": "vn-right-1" } ] kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Pod","metadata":
{"annotations":{"k8s.v1.cni.cncf.io/networks":"[
{ \"name\": \"vn-left-1\" }, { \"name\": \"vn-...
Status: Running
IP: 10.47.255.238
...<snipped>...
注釈では、k8s.v1.cni.cncf.io/network-status の下に […] リストが表示されます。これには、3つのアイテムがあり、それぞれの中括弧 {} で表されるキー値マッピングがあります。各波括弧には、1つのインターフェイスに関する情報が含まれます。割り当てられた IP、MAC、および所属する仮想ネットワーク。そのため、2つではなく3つのインターフェイスを pod に作成することになります。
IP アドレス10.47.255.238 を示す2つ目の項目に注目してください。このインターフェイスは、システムによって作成された、クラスター全体のデフォルトと呼ばれるデフォルトの pod ネットワークに接続されています。デフォルトのポッドネットワークは、すべての pod’s ネットワーク名前空間で常に稼働しているため、管理ネットワークとして見ることができます。機能的に’は、ユーザーが作成した仮想ネットワークとは大きく異なります。’ただし、それを削除することはできません。
’次に、ポッドにログインし、インターフェイスをリストして、IP アドレスと MAC を確認します。
$ kubectl exec -it webserver-mv sh / # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 37: eth0@if38: <BROADCAST,MULTICAST,UP,LOWER_UP,M- DOWN> mtu 1500 qdisc noqueue link/ether 02:87:98:cc:4e:98 brd ff:ff:ff:ff:ff:ff inet 10.47.255.238/12 scope global eth0 valid_lft forever preferred_lft forever 39: eth1@if40: <BROADCAST,MULTICAST,UP,LOWER_UP,M- DOWN> mtu 1500 qdisc noqueue link/ether 02:87:cf:6c:9a:98 brd ff:ff:ff:ff:ff:ff inet 10.10.10.250/24 scope global eth1 valid_lft forever preferred_lft forever 41: eth2@if42: <BROADCAST,MULTICAST,UP,LOWER_UP,M- DOWN> mtu 1500 qdisc noqueue link/ether 02:87:f9:f9:88:98 brd ff:ff:ff:ff:ff:ff inet 20.20.20.1/24 scope global eth2 valid_lft forever preferred_lft forever
1つの lo インターフェイスと3つのインターフェイスを Contrail CNI で接続し、それぞれに対応する仮想ネットワークから IP アドレスが割り当てられていることを確認できます。また、MAC アドレスは、kubectl に’記載されているものと一致することに注意してください。コマンド出力について説明します。
特定の状況下では、注釈に MAC アドレスを持つことが役立ちます。たとえば、サービス連鎖セクションでは、MAC アドレスを使用して適切なインターフェイスを見つける必要があるシナリオが実行されるため、仮想ネットワークから割り当てられた Kubernetes の正しい podIP を割り当てることができます。詳細については、こちらをご覧ください。
この’例では、一般的な Docker の画像ではなく Juniper cSRX の画像に基づいて pod が作成されると、マルチインターフェイスポッドがもう一度見られます。基本的な考え方は変わりません。