#概要
Kubernetes(以下k8s)のCNI(Container Network Interface)としてTungsten Fabric(OSS)/Contrail(Juniper社)というものがある。
前回、AWS上でTungesten FabricとKubernetesを簡単に触る方法を記載したが、Juniper社がvLABsという無償リモートラボでContrailとk8sを触る環境が用意されているため、そちらを使って、PODを作成してSerivice Load Balancerを利用して外部公開する、基本的なオペレーションを行なう方法を記載する。
1.Juniper vLabsアクセス方法とシナリオ概要
2.初期状態確認
3.サンプルシナリオ – アプリケーションデプロイとLoadBalancer外部接続
3-1.POD作成
3-2.Service type LoadBalancer作成
3-3.状態確認
4.参考資料
#1.Juniper vLabsアクセス方法とContrail & k8s シナリオ概要
vLABサイト
https://jlabs.juniper.net/vlabs/
vLABの利用方法はこちらも参照
アカウント作成後は、vLab Sandbox: Contrail Enterprise Multicloud with Kubernetes
のScenario Activity Guideで用意されている手順が確認できる。
BLUEPRINT:
[vLAB Official Demo] CEM and Kubernetes
• Contrail version R1910
• Kubernetes 1.12
※本ページは上記のバージョンを利用
※vLABでの予約はデフォルトでは3時間の利用。最大6時間。再利用は再度予約する必要がある。
ダイレクトアクセス方法
COMMANDS->"Add Allowed Network Prefixes"にて自身のGlobalIPを入力し、RUN 。
※これは、パブリックのvLABに接続するアドレスとなる。例として、こちらのサイトで外部接続のアドレスが確認可能。
※設定後、踏み台を経由せず、直接vLABの環境にアクセス可能となる。
※Add Allowed Network Prefixeを追加すると、各デバイスへのアクセス方法が記載されたメールが通知される。
通知されたアクセス先にログインできるか確認
[Contrail Command] Private Portが9091のもの
https://66.129.235.3:40004/
※メールで通知されるアドレスとポート番号にアクセス
UserName: admin
Password: contrail123
※ログインに時間を要す場合は、クッキーを削除。
[Tungsten Fabric Controller]
https://66.129.235.12:40010/
※メールで通知されるアドレスとポート番号にアクセス。
※Tungesten Fabric GUIはOSSのGUI。こちらをオペレーションすることも可能だが、今回はContrail Command GUIを主に利用する。
UserName: admin
Password: contrail123
[K8S Master]
※メールで通知されるアドレスとポート番号にアクセス。
$ ssh root@66.129.235.3 -p 40022
root@66.129.235.3's password: Juniper!1
[root@k8smaster ~]#
[K8S Node]
※メールで通知されるアドレスとポート番号にアクセス。
$ ssh root@66.129.235.3 -p 40027
root@66.129.235.3's password: Juniper!1
[root@k8snode1 ~]#
[vMX]
※メールで通知されるアドレスとポート番号にアクセス。
$ ssh root@66.129.235.3 -p 40041
Password: Juniper!1
--- JUNOS 18.3R1.9 Kernel 64-bit JNPR-11.0-20180816.8630ec5_buil
root@vMX1-GW:~ # cli
root@vMX1-GW>
※k8s masterのAPI ServerがContrail Controllerのcontrail-kube-managerにrequest
※各kubernates(以下k8s) NodesにはContrail vRouterが存在し、ネットワーク分割(VRF: Virtual Routing and Forwarding)、セキュリティー・ポリシー、パケットフォワーディング、SNAT等を実施
※k8sNodes間は、オーバーレイ接続
※vRouterとContrail Controllerはxmppにより情報交換
※vMXは外部接続するゲートウェイ
※設定変更によりgateweyless modeとして直接vRouterからアンダーレイ経由での接続も可能
※vMXとContrail ControllerはBGPにより経路交換
k8sとContrailの概要については、こちらも参照
#2.初期状態確認
Contrail CommandにLoginし、全てのコンポーネントのステータスがグリーンになっていることを確認
Infrastructure -> ServersにてContrail Controller 1台、K8S Master 1台、K8S Node 2台がデプロイされていることを確認
Overlay -> Networksにてk8S-default(GUIの右上にてプロジェクト選択可能)のVirtual Networkが3つ作成済みなことを確認
※k8s-default-pod-network: デフォルトで用意されているPOD用のネットワーク。k8s-pod-ipam(10.32.0.0/12)のIPAMがマッピンされている。
※k8s-default-service-network:デフォルトで用意されているService用のネットワーク。k8s-service-ipam(10.96.0.0/12)のIPAMがマッピンされている。
※External-net: 外部接続用のネットワーク。シナリオ用に事前設定されている状態。”Edit” にてCIDR(ネットワークサブネット10.40.0.0/24)、Floating Pool Name “External”、Route Targetが設定してあることが確認可能。
*デフォルトで用意されるk8s-default-service-network、k8s-default-pod-networkの説明はこちら
Overlay -> IP Address ManagementにてIPAMでそれぞれに払い出すサブネットを確認
Overlay -> Floating IPsの初期状態を確認
※10.96.0.1はk8s内部で利用するapiserverのcluster IPとなる。
※# kubectl exec pod-name -- env のKUBERNETES_SERVICE_HOST 環境変数でも確認可能
Floating IP Poolsとして仮想ネットワークのExternal-netで指定したExternalが定義されている
k8s masterノードにてk8sノード起動、Pod, Serviceの状態を確認
[root@k8smaster ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8smaster Ready master 214d v1.12.9
k8snode1 Ready <none> 214d v1.12.9
k8snode2 Ready <none> 214d v1.12.9
root@k8smaster ~]# kubectl get pods
No resources found.
[root@k8smaster ~]# kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 178d
k8s nodesノードにてContrail vRouterの起動状態を確認
[root@k8snode1 ~]# contrail-status
Pod Service Original Name State Id Status
rsyslogd running 06e2bdaaaad1 Up 5 hours
vrouter agent contrail-vrouter-agent running b15d1cc7db1b Up 5 hours
vrouter nodemgr contrail-nodemgr running 39ec47b78802 Up 5 hours
WARNING: container with original name '' have Pod or Service empty. Pod: '' / Service: 'rsyslogd'. Please pass NODE_TYPE with pod name to container's env
vrouter kernel module is PRESENT
== Contrail vrouter ==
nodemgr: active
agent: active
Infrastructure-> Cluster->Advanced->BGP Routersにて
vMXに対するBGP設定があることを確認 設定方法
vMXにてContrail ControllerとBGP Peeringできていることを確認
※vMXは外部接続ゲートウェイとして動作し、Contrail ControllerとBGPにて経路交換
root@vMX1-GW> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
bgp.rtarget.0
8 8 0 0 0 0
inet.0
0 0 0 0 0 0
bgp.l3vpn.0
0 0 0 0 0 0
bgp.evpn.0
0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
100.123.18.2 64512 2594 2883 0 0 21:33:04 Establ
bgp.rtarget.0: 8/8/8/0
bgp.l3vpn.0: 0/0/0/0
bgp.evpn.0: 0/0/0/0
vMXにて保持している経路情報を確認
k8sクラスタ関連のアドレス(10.x.x.x)を保持していないことを確認
※’contrail’という名前のipv4 table(inet.0)を確認
root@vMX1-GW> show route table contrail.inet.0
contrail.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 1d 23:29:43
> to 172.16.0.1 via lt-0/0/10.1
172.16.0.0/24 *[Direct/0] 1d 23:29:43
> via lt-0/0/10.1
172.16.0.100/32 *[Local/0] 1d 23:29:43
Local via lt-0/0/10.1
#3.サンプルシナリオ – アプリケーションデプロイとLoadBalancer外部接続
NGINX PODを2つ作成、LBを経由し外部アクセス (vLAB英語版記載シナリオ)
3-1. POD作成(deployment)
3-2. Service type LoadBalancer作成
3-3. 状態確認 (外部クライアントからの接続、Contrail Command GUI)
シナリオ確認用に事前に各アプリケーション起動用のマニフェストファイルが用意されていることを確認
[root@k8smaster ~]# cd examples/lab1/
[root@k8smaster lab1]# ls
deployment.yaml pod1.yaml pod3.yaml pod-red.yaml pol-front-back.yaml
namespace.yaml pod2.yaml pod-green.yaml pol-deny-all.yaml service.yaml
####3-1. POD作成(deployment)
※k8s PODとは、workloadの最小単位となり、1つ以上のコンテナから構成。POD内は同じIPアドレスが割り当てられる。
※Contrailでは、Virtual Machineとして扱う。
※k8s Deploymentとは、ReplicationSetを管理し、ローリングアップデートやロールバックなどを実現するリソース。
nginxのアプリケーションをデプロイするマニフェストファイルで起動
[root@k8smaster ~]# cat examples/lab1/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
run: my-nginx
replicas: 2
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 80
[root@k8smaster ~]# kubectl apply -f examples/lab1/deployment.yaml
deployment.apps/my-nginx created
作成されたPodを確認(マニフェストでreplicas:2と指定されているため、nginx Podが2つ作成) 。各PODのアドレスを確認すると、k8s-pod-ipam(10.32.0.0/12)から割り当てられているのがわかる。
[root@k8smaster ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
my-nginx-756f645cd7-242pp 1/1 Running 0 36s
my-nginx-756f645cd7-th7cw 1/1 Running 0 36s
[[root@k8smaster lab1]# kubectl get pods --output=wide
my-nginx-756f645cd7-76djb 1/1 Running 0 64s 10.47.255.252 k8snode2 <none>
my-nginx-756f645cd7-x4j5t 1/1 Running 0 64s 10.47.255.248 k8snode1 <none>
####3-2. Service type LoadBalancer作成
外部からDeployしたPodにアクセスするためにService(LoadBalancer)のファイルを確認し展開。
※k8s Serviceリソースとは、L4ロードバランシングを提供し、受信したトラフィックを複数のPODに負荷分散する。ClusterIP(クラスタ内部で利用する仮想IP), LoadBalancer(外部接続仮想IP)等の複数のtypeが存在する。
※ContrailではServiceは、ECMP Loadbalanderとして提供する。
※k8s LoadBalancer Serviceとは、クラスタ外の外部疎通性のある仮想IPを払い出す
※外部接続 -> Service -> POD接続となる。
[root@k8smaster ~]# cat examples/lab1/service.yaml
apiVersion: v1
kind: Service
metadata:
name: my-nginx
labels:
run: my-nginx
spec:
ports:
- port: 80
protocol: TCP
selector:
run: my-nginx
type: LoadBalancer
[root@k8smaster ~]# kubectl apply -f examples/lab1/service.yaml
service/my-nginx created
※上記サンプルは”run=my-ngin”のラベルのPODに対してトラフィックを転送
Serviceが作成できているか確認
*外部アクセス用のFloatingIP(10.40.0.3 – 外部ネットワークのExternal:10.40.0.0/24)がアサイン
*クラスタ内部用のCluster IP(10.96.21.23 – Service用のネットワーク:10.96.0.0/12 )がアサイン
*my-nginxのLoadBalancerのエンドポイントとして各POD(10.47.255.249:80, 10.47.255.252:80)
[root@k8smaster lab1]# kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 214d
my-nginx LoadBalancer 10.96.21.23 10.40.0.3 80:30640/TCP 5s
[root@k8smaster lab1]# kubectl get endpoints
NAME ENDPOINTS AGE
kubernetes 10.1.0.67:6443 214d
my-nginx 10.47.255.248:80, 10.47.255.252:80 22s
補足. 外部接続アドレス:Floating IP
k8sでは、外部接続をする場合、ServiceリソースとしてL4ロードバランシングや、IngressリソースとしてL7ロードバランシングを利用することで外部接続を行なう。
Contrailの場合は、フローティングIP、Fabric SNAT(アンダー接続)、Logical Routerなど様々な方法で外部接続することが可能。今回は、典型的な方法としてフローティングIPとして外部接続用のアドレスを用意し、クラスタの外部接続を行なう。
フローティングIPを利用することで、外部アドレスと内部アドレスの紐付けを行うことができ、外部からの接続も可能となる。
Contrail k8s環境の場合、Serviceリソース、Ingressリソースに加えて、フローティングIPを利用することで柔軟な接続が可能となる。
図.Floating IPワークフロー概要
vMXにLoginし、10.40.0.3がBGPでContrail Controllerから広報されていることを確認。
root@vMX1-GW> show route table contrail.inet.0
contrail.inet.0: 4 destinations, 5 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 22:03:36
> to 172.16.0.1 via lt-0/0/10.1
10.40.0.3/32 *[BGP/170] 00:02:48, MED 100, localpref 200, from 100.123.18.2
AS path: ?, validation-state: unverified
> via gr-0/0/10.32771, Push 32
[BGP/170] 00:02:48, MED 100, localpref 200, from 100.123.18.2
AS path: ?, validation-state: unverified
> via gr-0/0/10.32770, Push 32
172.16.0.0/24 *[Direct/0] 22:03:36
> via lt-0/0/10.1
172.16.0.100/32 *[Local/0] 22:03:36
Local via lt-0/0/10.1
10.40.0.3経路は2つのオーバーレイのECMPとなり、protocol next-hopとして各k8s nodesがとなっている。
root@vMX1-GW> show route table contrail.inet.0 10.40.0.3 detail
contrail.inet.0: 4 destinations, 5 routes (4 active, 0 holddown, 0 hidden)
10.40.0.3/32 (2 entries, 1 announced)
*BGP Preference: 170/-201
Route Distinguisher: 10.1.0.66:3
Next hop type: Indirect, Next hop index: 0
Address: 0xce329b0
Next-hop reference count: 3
Source: 100.123.18.2
Next hop type: Router, Next hop index: 631
Next hop: via gr-0/0/10.32771, selected
Label operation: Push 39
Label TTL action: prop-ttl
Load balance label: Label 39: None;
Label element ptr: 0xce31f80
Label parent element ptr: 0x0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 0x1f9
Protocol next hop: 10.1.0.66
Label operation: Push 39
Label TTL action: prop-ttl
--- 省略 ---
BGP Preference: 170/-201
Route Distinguisher: 10.1.0.194:4
Next hop type: Indirect, Next hop index: 0
Address: 0xce32710
Next-hop reference count: 2
Source: 100.123.18.2
Next hop type: Router, Next hop index: 0
Next hop: via gr-0/0/10.32770, selected
Label operation: Push 32
Label TTL action: prop-ttl
Load balance label: Label 32: None;
Label element ptr: 0xce32760
Label parent element ptr: 0x0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 0x0
Protocol next hop: 10.1.0.194
Label operation: Push 32
Label TTL action: prop-ttl
--- 省略 ---
####3-3. 状態確認 (外部クライアントからの接続、Contrail Command GUI)
Cluster外部のクライアント (JumpHost)にLoginし、podにアクセスできるか確認。
※メールで通知されるアドレスとポート番号にアクセス。
※PODで起動しているnginxにcurlでアクセス。
[root@csg ~]# curl 10.40.0.3
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
--snip--
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
Contrail Command確認(Pod、FIP 、Service)
Overlay -> VirtualNetworksにて、k8s-default-pod-networkのVNにPodが2つ接続されていることがわかる。
Contrail CommandでもExternalのPoolからFloating IP(10.40.0.3)が割り当てられたのがわかる。
Services -> LoadBalancersにて、default__my-nginxというLoadBalancerが作成されており、FloatingIP(10.40.0.3)がアサインされている。
※default_my-nginxをクリックするlister portやPool Membersを確認可能。
※ ただし、vLab環境の場合、Pool MembersのMonitorは動作負荷。
OVERLAY -> Virtual Portsでも各Floating IPとFixes IPのマッピングが確認可能。
今後、namespaceの分割、ingress、Network Policy、Contrail Security、Service Chaining(cSRX)などのシナリオの基本オペレーションも記載予定。
#4.参考ドキュメント
DAY ONE: BUILDING CONTAINERS WITH KUBERNETES AND CONTRAIL
DAY ONE : KubernetesとContrailを使用したコンテナの構築 (DAY ONEの日本語翻訳)
[Contrail Networking Architecture Guide]
(https://www.juniper.net/documentation/en_US/release-independent/solutions/information-products/pathway-pages/sg-010-contrail-networking-arch-guide.pdf)
contrail-controller/wiki/Kubernetes
[Single click installation of RedHat OpenShift with Contrail SDN (on AWS)]
(https://github.com/Juniper/openshift-ansible/wiki/Single-click-installation-of-RedHat-OpenShift-with-Contrail-SDN-(on-AWS))
https://github.com/Juniper/contrail-controller/tree/master/src/container/cni
https://github.com/Juniper/contrail-controller/tree/master/src/container/kube-manager
Contrail Networking Installation and Upgrade Guide
以上