L2-only virtual-network
Tungsten の仮想ネットワークは、通常、L3の動作を含んだものとなる。
例えば、vrouter が提供するgwのipに対しては、仮想ネットワーク内のvmからは、常にping が飛ぶ状態となっている。
ただし、Tungsten の仮想ネットワーク定義は、これ以外に、L2だけを提供するための設定も存在する。
https://bugs.launchpad.net/juniperopenstack/+bug/1471637
※ 設定方法としては以下の通り、仮想ネットワークの定義から、Advanced Options > Forwarding Mode > L2 Only を選択する
このモードの仮想ネットワークでは、vrouter はルーターとしての機能を提供しなくなり、L2 ブリッジと同様に振る舞う。
※ このため、gw ip へのping や、dhcpでのip付与、compute からの 169.254.0.x への ssh 等は使用できなくなる。
この場合も、手動で各 vm に ip を割り振れば、vm 間の疎通は、通常通り可能となる。
※ 以下では、以前構築したkolla openstack (compute は2台に増やしている)
http://aaabbb-200904.hatenablog.jp/entry/2018/04/28/215922
の仮想ネットワークをL2 Onlyに変更し、2台立ち上げたvyos で、お互いにping が飛ぶことを確認している。
(vyos1) set interface ethernet eth1 address 192.168.100.5/24 (vyos2) set interface ethernet eth1 address 192.168.100.6/24
また、この場合のvlan タグの動作だが、片方のVNFから出てきた際についたタグは、(compute をまたいだ場合も) そのまま伝搬され、仮想ネットワーク内の別vmに到達可能、という結果となった。
※ 2台のvyos に同じvlan インターフェースをつけてping を実行することで確認
(vyos1) set interfaces ethernet eth1 vif 101 address 192.168.101.11/24 (vyos2) set interfaces ethernet eth1 vif 101 address 192.168.101.12/24
また、compute上でパケットキャプチャを行った場合も、行き、帰りともに vlan タグがついていることを確認できた。
[root@ip-172-31-3-107 ~]# tcpdump -i tap47a437bf-15 -n -e tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tap47a437bf-15, link-type EN10MB (Ethernet), capture size 262144 bytes 15:05:12.108450 02:47:a4:37:bf:15 > 02:b6:3c:4f:35:fa, ethertype 802.1Q (0x8100), length 102: vlan 101, p 0, ethertype IPv4, 192.168.101.11 > 192.168.101.12: ICMP echo request, id 3878, seq 1, length 64 15:05:12.109455 02:b6:3c:4f:35:fa > 02:47:a4:37:bf:15, ethertype 802.1Q (0x8100), length 102: vlan 101, p 0, ethertype IPv4, 192.168.101.12 > 192.168.101.11: ICMP echo reply, id 3878, seq 1, length 64 15:05:13.110547 02:47:a4:37:bf:15 > 02:b6:3c:4f:35:fa, ethertype 802.1Q (0x8100), length 102: vlan 101, p 0, ethertype IPv4, 192.168.101.11 > 192.168.101.12: ICMP echo request, id 3878, seq 2, length 64 15:05:13.111306 02:b6:3c:4f:35:fa > 02:47:a4:37:bf:15, ethertype 802.1Q (0x8100), length 102: vlan 101, p 0, ethertype IPv4, 192.168.101.12 > 192.168.101.11: ICMP echo reply, id 3878, seq 2, length 64 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel [root@ip-172-31-3-107 ~]#
vlan subinterface
Tungsten Fabric では、VNFからvlanタグがついたパケットが送出された場合に、別の仮想ネットワークにパケットを入れる、という制御が実施できる。
多数のVRFで同じVNFを共有する場合、等に活用できるのではなかろうか。
※ 設定方法としては、以下の動画の通り、設定を行いたいポートで、'Add Subinterface' をクリックし、VNに紐付ける、という内容となる。
https://www.youtube.com/watch?v=ANhBQe_DS2E
k8sのrollout機能
kubernetes では、rollout という機能で、無停止でのアプリケーション更新を実施できる。(deployment定義時に使用可能)
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
今回は、TF上のdeploymentで上記を行った場合に、アプリケーションが停止するタイミングが発生しないことを確認する。
実施内容としては、以下のサンプルyaml 2つを使って、deployment / service を定義し、
https://github.com/tnaganawa/contrail-k8s-tutorial/blob/master/yml/3_contrail-cni-features/3_ingress/nginx-deployment.yaml
https://github.com/tnaganawa/contrail-k8s-tutorial/blob/master/yml/3_contrail-cni-features/3_ingress/nginx-svc.yaml
[root@ip-172-31-4-195 ~]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE cirros1 1/1 Running 0 7m 10.47.255.248 ip-172-31-9-61.ap-northeast-1.compute.internal nginx-deployment-85f794d94b-cxp4p 1/1 Running 0 4m 10.47.255.250 ip-172-31-9-61.ap-northeast-1.compute.internal nginx-deployment-85f794d94b-m9zrb 1/1 Running 0 4m 10.47.255.247 ip-172-31-9-61.ap-northeast-1.compute.internal [root@ip-172-31-4-195 ~]# [root@ip-172-31-4-195 ~]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 2h nginx-svc ClusterIP 10.99.250.199 <none> 80/TCP 9m [root@ip-172-31-4-195 ~]#
以下のコマンドでコンテナのrollout を実施している。
# kubectl edit deployment/nginx-deployment (container image のバージョンを変更: 1.7.9 -> 1.9.2)
適用がうまくいった場合、新規のcontainerが作成され、古いバージョンのcontainerが停止される、という動作となる。
※ 更新状況は、以下のように確認が可能
[root@ip-172-31-4-195 3_ingress]# kubectl rollout status deployment/nginx-deployment Waiting for rollout to finish: 1 out of 2 new replicas have been updated... Waiting for rollout to finish: 1 out of 2 new replicas have been updated... Waiting for rollout to finish: 1 out of 2 new replicas have been updated... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... deployment "nginx-deployment" successfully rolled out [root@ip-172-31-4-195 3_ingress]#
あわせて、cirros のpod を1台作成し、1秒ごとにserviceのipに対してcurl を発行し、アクセスが途切れないことを確認している。
※ TFでは、container の増減に合わせてbgp経路の更新を行っているのだが、rollout のように新規のコンテナが作られた後、古いコンテナが削除される、という動作についても、特に問題なく追随出来るらしい
/ # while true; do date; curl -I 10.99.250.199 2> /dev/null | head -n 1 ; sleep 1; done Thu May 3 10:24:52 UTC 2018 HTTP/1.1 200 OK Thu May 3 10:24:53 UTC 2018 HTTP/1.1 200 OK Thu May 3 10:24:54 UTC 2018 HTTP/1.1 200 OK (snip)
TF上でpacemakerを動かしてみたときの動作
Tungsten のarp対応ロジックは、HAクラスタ等で使われる gratuitous arp にも対応している。
https://github.com/Juniper/contrail-controller/wiki/Contrail-VRouter-ARP-Processing
サンプルとして、k8s上のcentos7で、pacemakerを動かして動作を確認してみている。
※ pacemaker の設定については、以下を参照:
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/high_availability_add-on_administration/ch-startup-haaa
準備として、まず、以下のようなyaml を使って、systemd 使用可能な centos pod を2つ (以下、centos1, centos2) 作成する。
apiVersion: v1
kind: Pod
metadata:
name: centos1
labels:
name: centos1
spec:
containers:
- name: centos1
image: centos/systemd
securityContext:
privileged: trueこのあと、以下のようなコマンドを順に発行し、haクラスタの構成を行う。
yum install pacemaker pcs which passwd hacluster systemctl start pcsd.service vi /etc/hosts (/etc/hosts に centos1/centos2 のipをそれぞれ追記) pcs cluster auth centos1 centos2 (先ほど設定した、haclusterユーザーのパスワードを入力) pcs cluster setup --start --name cluster1 centos1 centos2 pcs property set stonith-enabled=false pcs cluster enable --all
※ なお、yum でパッケージの取得を行う際には、default:k8s-default-pod-network で、Advanced Option > SNAT にチェックをつける必要がある。
https://github.com/Juniper/contrail-specs/blob/master/distributed-snat.md
この後、クラスタにresource の定義を実施し、vipを設定する。
pcs resource create VirtualIP IPaddr2 ip=10.47.255.11 cidr_netmask=24
うまくクラスタが設定されると、ステータス確認で以下のような出力が得られる。
[root@centos1 /]# pcs status Cluster name: cluster1 WARNING: no stonith devices and stonith-enabled is not false Stack: corosync Current DC: centos2 (version 1.1.16-12.el7_4.8-94ff4df) - partition with quorum Last updated: Thu May 3 07:42:56 2018 Last change: Thu May 3 07:41:51 2018 by root via cibadmin on centos2 2 nodes configured 1 resource configured Online: [ centos1 centos2 ] Full list of resources: VirtualIP (ocf::heartbeat:IPaddr2): Started centos1 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/disabled [root@centos1 /]#
また、resourceが起動しているcentos1 に、vip が付与されていることを確認しておく。
[root@centos1 /]# ip -o a 1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever 1: lo inet6 ::1/128 scope host \ valid_lft forever preferred_lft forever 9: eth0 inet 10.47.255.251/12 scope global eth0\ valid_lft forever preferred_lft forever 9: eth0 inet 10.47.255.11/24 scope global eth0\ valid_lft forever preferred_lft forever 9: eth0 inet6 fe80::80a6:33ff:fedb:b209/64 scope link \ valid_lft forever preferred_lft forever [root@centos1 /]#
この状態で、同じサブネットに cirros を立ち上げてvip にping を発行するのだが、ここまでの設定だと、TF 上で許可設定が無いため、pingが飛ばない状態になる。
/ # ip -o a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1\ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever 1: lo inet6 ::1/128 scope host \ valid_lft forever preferred_lft forever 15: eth0@if16: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue \ link/ether 02:fa:bb:e6:12:4e brd ff:ff:ff:ff:ff:ff 15: eth0 inet 10.47.255.250/12 scope global eth0\ valid_lft forever preferred_lft forever 15: eth0 inet6 fe80::58f0:7aff:fe95:ee89/64 scope link \ valid_lft forever preferred_lft forever / # / # / # / # ping 10.47.255.11 PING 10.47.255.11 (10.47.255.11): 56 data bytes ^C --- 10.47.255.11 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss / #
centos1 用のvmi に、vip (ここでは、10.47.255.11) の使用を許可するには、webui の、Configure > Networking > Ports から、'Advanced Option > Allowed Address Pair' を使って、許可を行う必要がある。
設定後、以下のようにping が飛ぶようになる。
※ 同様に centos2 の方のport にもallowed address pair を設定しておく。
/ # ping 10.47.255.11 PING 10.47.255.11 (10.47.255.11): 56 data bytes 64 bytes from 10.47.255.11: seq=0 ttl=63 time=1.031 ms 64 bytes from 10.47.255.11: seq=1 ttl=63 time=0.492 ms ^C --- 10.47.255.11 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.492/0.761/1.031 ms / #
また、以下のコマンドで、HAクラスタのresource の移動を行い、centos2 に移った場合も、ping が飛ぶことを確認しておく。
[root@centos1 ~]# pcs resource move VirtualIP centos2 [root@centos1 ~]# pcs status Cluster name: cluster1 Stack: corosync Current DC: centos2 (version 1.1.16-12.el7_4.8-94ff4df) - partition with quorum Last updated: Thu May 3 08:07:42 2018 Last change: Thu May 3 08:07:36 2018 by root via crm_resource on centos1 2 nodes configured 1 resource configured Online: [ centos1 centos2 ] Full list of resources: VirtualIP (ocf::heartbeat:IPaddr2): Started centos2 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/disabled [root@centos1 ~]#
この後、cirrosからvipにping を打ちながら、切り替えを行う、という対応を実施してみたのだが、上記で使用している、k8s デフォルトの仮想ネットワーク(default:k8s-default-pod-network) の場合、なぜか切り替えに10秒程度かかる事象が発生した、、(原因不明だが、k8s-default-pod-network には、いくつかk8s用のポリシーが設定されていることと、/12と広いサブネットが設定されていること、等が関係しているかもしれない)
このため、以下の内容で、別途仮想ネットワークを作成し、再度、同じ切り替えを実施してみている。
Name: vn1 Subnet: 10.0.1.0/24
この場合、切り替え時のパケットロスは1秒程度、という結果になった。
/ # ping 10.0.1.11 PING 10.0.1.11 (10.0.1.11): 56 data bytes 64 bytes from 10.0.1.11: seq=0 ttl=64 time=0.446 ms 64 bytes from 10.0.1.11: seq=1 ttl=64 time=0.054 ms 64 bytes from 10.0.1.11: seq=2 ttl=64 time=0.082 ms 64 bytes from 10.0.1.11: seq=3 ttl=64 time=0.058 ms : centos1 -> centos2 の切り替えを実施 64 bytes from 10.0.1.11: seq=5 ttl=64 time=1.342 ms 64 bytes from 10.0.1.11: seq=6 ttl=64 time=0.482 ms 64 bytes from 10.0.1.11: seq=7 ttl=64 time=0.661 ms 64 bytes from 10.0.1.11: seq=8 ttl=64 time=0.574 ms 64 bytes from 10.0.1.11: seq=9 ttl=64 time=0.597 ms 64 bytes from 10.0.1.11: seq=10 ttl=64 time=0.538 ms 64 bytes from 10.0.1.11: seq=11 ttl=64 time=0.571 ms 64 bytes from 10.0.1.11: seq=12 ttl=64 time=0.532 ms : centos2 -> centos1 の切り替えを実施 64 bytes from 10.0.1.11: seq=14 ttl=64 time=0.337 ms 64 bytes from 10.0.1.11: seq=15 ttl=64 time=0.051 ms 64 bytes from 10.0.1.11: seq=16 ttl=64 time=0.075 ms 64 bytes from 10.0.1.11: seq=17 ttl=64 time=0.074 ms ^C --- 10.0.1.11 ping statistics --- 18 packets transmitted, 16 packets received, 11% packet loss round-trip min/avg/max = 0.051/0.404/1.342 ms / #
上記の結果を見る限り、(環境に合わせて工夫は必要だが) 現在同じような方法でHAクラスタを組んでいる部分についても、仮想ネットワークに移せる可能性がある、といえるのではなかろうか。
TungstenFabricとVyOSのBGPaaS
Tungsten Fabric の機能の一つに、BGPaaS という機能がある。
※ ユースケースとしては以下を参照
https://blueprints.launchpad.net/juniperopenstack/+spec/bgp-as-a-service
https://blueprints.launchpad.net/juniperopenstack/+spec/bgp-as-a-service-v2
https://networkop.co.uk/blog/2018/01/02/os-contrail/
今回は、以前構築した k8s+TF4.0 の環境で、
( http://aaabbb-200904.hatenablog.jp/entry/2017/10/15/034243 )
vyos のコンテナを動かし、実際にvrouterとvyos間でbgpがつながり、VRF内の経路がVNFに挿入されることを確認してみる。
※ テスト用の構成であり、実際のユースケースを想定したものではないので、念のため
まず、TFのwebuiから、仮想ネットワークを以下の情報で作成する。
name: vn1 subnet: 10.0.1.0/24
その後、vyos 用のコンテナを、以下の内容で作成する。
※ command と privileged: true を指定しないと、うまく起動できないので注意
apiVersion: v1
kind: Pod
metadata:
name: vyos1
labels:
name: vyos1
annotations: {
"opencontrail.org/network" : '{"domain":"default-domain", "project": "default", "name":"vn1"}'
}
spec:
containers:
- name: vyos1
image: 2stacks/vyos
command:
- /sbin/init
securityContext:
privileged: trueこのあと、vyos 側で以下のコンフィグを投入し、vrouter の gw と、bgp を設定する。
# kubectl exec -it vyos1 vbash # su - vyos > configure # set protocols bgp 65311 neighbor 10.0.1.1 remote-as 64512 # commit # exit
合わせて、TF側では、以下のように、BGPaaSの設定を実施する。
Configure > Services > BGP as a Service > Create name: bgpaas11 autonomous system: 65311 virtual machine interface: (vyosのvmiを選択) advanced options > ip address: 10.0.1.3 (vyosのipを記載) advanced options > hold time: 180
うまくいくと、以下のように、vyos 側でbgpがEstablished になり、TF 内の経路を受け取っていることが確認できる。
vyos@vyos:~$ show ip bgp summary
BGP router identifier 10.0.1.3, local AS number 65311
IPv4 Unicast - max multipaths: ebgp 1 ibgp 1
RIB entries 1, using 96 bytes of memory
Peers 1, using 4560 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.1.1 4 64512 4 5 0 0 0 00:01:11 1
Total number of neighbors 1
vyos@vyos:~$
vyos@vyos:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
K>* 0.0.0.0/0 via 10.0.1.1, eth0
C>* 10.0.1.0/24 is directly connected, eth0
B>* 10.0.1.3/32 [20/100] via 10.0.1.1, eth0, 00:00:24 <-- TF VRF内の経路がVNFに挿入されている
C>* 127.0.0.0/8 is directly connected, lo
vyos@vyos:~$ また、TF側からは、Monitor > Infrastructure > Control Nodes > (control node名) > Peers から、BGP peerの状態を確認できる。
Tungsten Fabricのインストール(k8s, kolla, k8s&kolla)
Tungsten Fabric のインストールをAWS上で試してみたので、その時のメモとなる。
インストール時の組み合わせとしては、
1. k8s
2. kolla openstack
3. k8s & kolla openstack
の3パターンで実施している。
※ このうち、3番目の組み合わせは、最近できた仕組みとなる
全体を通じて、環境としては、AWS 上のMarketPlaceで、"CentOS 7 (x86_64) - with Updates HVM" と記載されている、Centos7.4のインスタンスを使用している。(ami-91c4d3ed, ログインユーザー名は centos)
また、Disk は20GBで作成するようにした。
2018/5/19 追記
centos7.5が出た影響なのか、もともとのami とcontrailnightly:latest の組み合わせだとvrouter.ko の読み込みが出来なくなっていた、、
https://bugs.launchpad.net/juniperopenstack/+bug/1764537
※
ifconfig vhost0
docker logs vrouter_vrouter-agent_1
等で確認可能
centos7.5用のami (ami-3185744e) でk8sの手順を実施し、動作することを確認している
2018/7/22 追記
upstream の変更に合わせて記述を修正:
- instance.yaml に global_configuration の定義が必要になった (空の場合も) ので、追記
- TFインストール前に install_k8s.yaml, install_openstack.yaml を実施するようになったため、コマンドを追記
- minimum_diskGB を設定する際のパス, container名が変更になったので追記
- admin-openrc.sh の置き場所が変わったのでパスを修正
k8s
元の資料は以下となる。
https://github.com/Juniper/contrail-ansible-deployer/wiki/Contrail-microservice-installation-with-kubernetes
インスタンス種別としては、t2.large x 2 を使用した。
事前準備として、master ノード上で、以下のコマンドを発行し、パッケージをインストールしておく
# yum -y install epel-release git ansible net-tools
また、master ノードで以下のコマンドを発行し、
# ssh-keygen
できた/root/.ssh/id_rsa.pubを master ノード, slave ノード の /root/.ssh/authorized_keys に追記しておく。
※ あわせて、各ノードでntpも設定しておく。
yum -y install ntp service ntpd start
上記が終わったら、以下のコマンドで、インストール用のplaybook を流す準備を行っていく。
# git clone https://github.com/Juniper/contrail-ansible-deployer.git
# cd contrail-ansible-deployer
# vi config/instances.yaml
provider_config:
bms:
ssh_user: root
ssh_public_key: /root/.ssh/id_rsa.pub
ssh_private_key: /root/.ssh/id_rsa
domainsuffix: local
instances:
bms1:
provider: bms
roles:
config_database:
config:
control:
analytics_database:
analytics:
webui:
k8s_master:
kubemanager:
ip: 172.31.14.34 # masterノードのip
bms2:
provider: bms
roles:
vrouter:
k8s_node:
ip: 172.31.4.240 # slave ノードのip
contrail_configuration:
CONTAINER_REGISTRY: opencontrailnightly
CONTRAIL_VERSION: latest
KUBERNETES_CLUSTER_PROJECT: {}
global_configuration: ### 2018/7/22追記この後、以下の3つのplaybook で、インストールが実施される。
ansible-playbook -i inventory/ playbooks/configure_instances.yml ※ 10分ほどかかる ansible-playbook -e orchestrator=kubernetes -i inventory/ playbooks/install_k8s.yml ## 2018/7/22 追記 ※ 5分ほどかかる ansible-playbook -e orchestrator=kubernetes -i inventory/ playbooks/install_contrail.yml ※ 20分ほどかかる
動作確認としては、まず、以下のコマンドで、全てのコンポーネントのステータスがactive になっていることを確認する。
# contrail-status
※
nodemgr: initializing (Disk for DB is too low.)
が表示された場合、以下を実施し、再度 contrail-status を実施する。
docker exec -it config_nodemgr_1 sed -i 's/#minimum_diskGB=4/minimum_diskGB=4/' /etc/contrail/contrail-config-nodemgr.conf docker restart config_nodemgr_1 docker exec -it analyticsdatabase_nodemgr_1 sed -i 's/#minimum_diskGB=4/minimum_diskGB=4/' /etc/contrail/contrail-database-nodemgr.conf docker restart analyticsdatabase_nodemgr_1 (2018/7/22追記) docker exec -it config_database_nodemgr_1 sed -i 's/#minimum_diskGB=4/minimum_diskGB=4/' /entrypoint.sh docker restart config_database_nodemgr_1 docker exec -it analytics_database_nodemgr_1 sed -i 's/#minimum_diskGB=4/minimum_diskGB=4/' /entrypoint.sh docker restart analytics_database_nodemgr_1
上記が確認できたら、以下のようにcirrosを投入し、コンテナの起動と gw への疎通が出来ることを確認する。
※ k8s yaml としては以下を使用: https://github.com/tnaganawa/contrail-k8s-tutorial/tree/master/yml/1_initial
[root@ip-172-31-14-34 1_initial]# kubectl create -f cirros1.yaml pod "cirros1" created [root@ip-172-31-14-34 1_initial]# [root@ip-172-31-14-34 1_initial]# kubectl create -f cirros2.yaml pod "cirros2" created [root@ip-172-31-14-34 1_initial]# [root@ip-172-31-14-34 1_initial]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE cirros1 1/1 Running 0 1m 10.47.255.251 ip-172-31-4-240.ap-northeast-1.compute.internal cirros2 1/1 Running 0 12s 10.47.255.250 ip-172-31-4-240.ap-northeast-1.compute.internal [root@ip-172-31-14-34 1_initial]# [root@ip-172-31-14-34 1_initial]# kubectl exec -it cirros1 sh / # ip -o a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1\ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever 1: lo inet6 ::1/128 scope host \ valid_lft forever preferred_lft forever 11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue \ link/ether 02:56:17:0e:4a:4a brd ff:ff:ff:ff:ff:ff 11: eth0 inet 10.47.255.251/12 scope global eth0\ valid_lft forever preferred_lft forever 11: eth0 inet6 fe80::20a8:92ff:fe11:6d80/64 scope link \ valid_lft forever preferred_lft forever / # ping 10.47.255.254 PING 10.47.255.254 (10.47.255.254): 56 data bytes 64 bytes from 10.47.255.254: seq=0 ttl=64 time=0.457 ms 64 bytes from 10.47.255.254: seq=1 ttl=64 time=0.196 ms ^C --- 10.47.255.254 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.196/0.326/0.457 ms / #
合わせて、以下のようなコマンドで contrail webui までの疎通を可能にし、webui が開けることを確認する。(id/pass は admin:contrail123)
ssh -L 8143:127.0.0.1:8143 -i (awsのpem) centos@(master ノードのip)
※スクリーンショットはこちら
kolla openstack
元の資料は以下となる。
https://github.com/Juniper/contrail-ansible-deployer/wiki/Contrail-with-Kolla-Ocata
k8s の場合とほぼ同じなので、コマンドのみ列記していく。
※ インスタンス種別としては、t2.2xlarge x 1 を使用した (t2.xlarge だと、メモリ不足で一部のプロセスが起動しなかった、、)
yum -y install epel-release
yum -y install git ansible-2.4.2.0
yum -y install ntp
service ntpd start
ssh-keygen
cd .ssh/
cat id_rsa.pub >> authorized_keys
cd
git clone http://github.com/Juniper/contrail-ansible-deployer
cd contrail-ansible-deployer
vi config/instances.yaml
(以下を記述)
provider_config:
bms:
ssh_pwd: root
ssh_user: root
domainsuffix: local
instances:
bms1:
provider: bms
ip: 172.31.2.25 # ec2 インスタンスのip
roles:
config_database:
config:
control:
analytics_database:
analytics:
webui:
vrouter:
openstack:
openstack_compute:
contrail_configuration:
RABBITMQ_NODE_PORT: 5673
AUTH_MODE: keystone
KEYSTONE_AUTH_URL_VERSION: /v3
kolla_config:
kolla_globals:
enable_haproxy: no
kolla_passwords:
keystone_admin_password: contrail123 # adminユーザーのパスワード
global_configuration: ### 2018/7/22追記
ansible-playbook -i inventory/ playbooks/configure_instances.yml
※ 10分ほどかかる
ansible-playbook -i inventory/ playbooks/install_openstack.yml
※ 20分ほどかかる
ansible-playbook -i inventory/ -e orchestrator=openstack playbooks/install_contrail.yml
※ 10分ほどかかるインストールが完了したら、aws での環境用に以下の設定変更を実施する。(nested kvm が使用できないことへの対応)
vi /etc/kolla/nova-compute/nova.conf [libvirt] に以下を追記 virt_type=qemu cpu_mode=none docker restart nova_compute
openstack 上にcirros を作成し、ping疎通が取れることを確認する。
yum install -y gcc python-devel wget
pip install python-openstackclient
pip install python-ironicclient
source /etc/kolla/admin-openrc.sh
source /etc/kolla/kolla-toolbox/admin-openrc.sh ## 2018/7/22追記
wget http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img
openstack image create cirros2 --disk-format qcow2 --public --container-format bare --file cirros-0.4.0-x86_64-disk.img
openstack network create testvn
openstack subnet create --subnet-range 192.168.100.0/24 --network testvn subnet1
openstack flavor create --ram 512 --disk 1 --vcpus 1 m1.tiny
NET_ID=`openstack network list | grep testvn | awk -F '|' '{print $2}' | tr -d ' '`
openstack server create --flavor m1.tiny --image cirros2 --nic net-id=${NET_ID} test_vm1
openstack server create --flavor m1.tiny --image cirros2 --nic net-id=${NET_ID} test_vm2
※ horizon/webuiへのアクセスのため、ログイン時に、以下のようなssh port forward を使用した。
ssh -L 8143:127.0.0.1:8143 -L 8080:172.31.2.25:80 -L 6080:172.31.2.25:6080 -i (awsのpem) centos@(masterノードのip)
k8s & kolla openstack
元々openstack と k8s は、どちらもvxlan 等を使って、ネットワークセグメンテーションを実施しているのだが、両方を一つのcontroller で管理する、という仕組みは、(知る限りでは) 今まで、あまり出てきていなかったように思う。
ただ、仕組み上は、同時に使えた方が便利と思われるので、今後はこちらのような構成が一般的になっていくのかもしれない。
今回は、インスタンスの種別として、 t2.2xlarge x 1 (masterノード用), t2.large x 1 (slaveノード用) を使用した。
コマンドは、kolla openstack の時と同じなので、 config/instances.yaml の中身のみ記載する。
※ playbook が流れきるまで、40分程度 必要となる。
provider_config:
bms:
ssh_pwd: root
ssh_user: root
domainsuffix: local
instances:
bms101:
provider: bms
ip: 172.31.15.178 # masterノードのip
roles:
config_database:
config:
control:
analytics_database:
analytics:
webui:
k8s_master:
kubemanager:
openstack:
bms102:
provider: bms
ip: 172.31.4.212 # slaveノードのip
roles:
vrouter:
k8s_node:
openstack_compute:
global_configuration:
CONTAINER_REGISTRY: opencontrailnightly
contrail_configuration:
CONTAINER_REGISTRY: opencontrailnightly
CONTRAIL_VERSION: latest
UPGRADE_KERNEL: true
RABBITMQ_NODE_PORT: 5673
AUTH_MODE: keystone
KEYSTONE_AUTH_URL_VERSION: /v3
KEYSTONE_AUTH_ADMIN_PASSWORD: contrail123 # adminユーザーのパスワード
CLOUD_ORCHESTRATOR: openstack
kolla_config:
customize:
nova.conf: |
[libvirt]
virt_type=qemu
cpu_mode=none
kolla_globals:
enable_haproxy: "no"
enable_ironic: "no"
enable_swift: "no"
動作確認としても、k8s, kolla openstack 単独の場合と同じで、cirros を作成し、疎通を確かめていく。
作成後の確認結果を載せておく。
(openstack) [root@ip-172-31-15-178 1_initial]# nova list +--------------------------------------+------+--------+------------+-------------+---------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+------+--------+------------+-------------+---------------+ | aa746031-2726-49fc-bcaf-83857ab80325 | vm1 | ACTIVE | - | Running | net1=10.1.1.3 | | 7104659c-870f-4105-a09a-aba33daa47c8 | vm2 | ACTIVE | - | Running | net1=10.1.1.4 | +--------------------------------------+------+--------+------------+-------------+---------------+ [root@ip-172-31-15-178 1_initial]# [root@ip-172-31-4-212 ~]# ssh cirros@169.254.0.4 The authenticity of host '169.254.0.4 (169.254.0.4)' can't be established. ECDSA key fingerprint is SHA256:vQ1pnyAy/vAmsvl5XhF4ukwIdoNx8e/p/RaJIA2sqFw. ECDSA key fingerprint is MD5:aa:80:67:5a:33:37:d7:7b:73:bb:25:be:b9:12:0e:e5. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '169.254.0.4' (ECDSA) to the list of known hosts. cirros@169.254.0.4's password: Permission denied, please try again. cirros@169.254.0.4's password: $ ip -o a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1\ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever 1: lo inet6 ::1/128 scope host \ valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000\ link/ether 02:fe:5a:fc:ba:3d brd ff:ff:ff:ff:ff:ff 2: eth0 inet 10.1.1.3/24 brd 10.1.1.255 scope global eth0\ valid_lft forever preferred_lft forever 2: eth0 inet6 fe80::fe:5aff:fefc:ba3d/64 scope link \ valid_lft forever preferred_lft forever $ $ ping 10.1.1.4 PING 10.1.1.4 (10.1.1.4): 56 data bytes 64 bytes from 10.1.1.4: seq=0 ttl=64 time=11.855 ms 64 bytes from 10.1.1.4: seq=1 ttl=64 time=2.957 ms ^C --- 10.1.1.4 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 2.957/7.406/11.855 ms $ (k8s) [root@ip-172-31-15-178 1_initial]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE cirros1 1/1 Running 0 36s 10.47.255.251 ip-172-31-4-212.ap-northeast-1.compute.internal cirros2 1/1 Running 0 20s 10.47.255.250 ip-172-31-4-212.ap-northeast-1.compute.internal [root@ip-172-31-15-178 1_initial]# [root@ip-172-31-15-178 ~]# kubectl exec -it cirros1 sh / # / # ping 10.47.255.250 PING 10.47.255.250 (10.47.255.250): 56 data bytes 64 bytes from 10.47.255.250: seq=0 ttl=63 time=0.552 ms 64 bytes from 10.47.255.250: seq=1 ttl=63 time=0.062 ms ^C --- 10.47.255.250 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.062/0.307/0.552 ms / # / # / # [root@ip-172-31-15-178 ~]#
合わせて、webui から Tungsten Fabricの状態を確認する。
※ interfaces 欄に openstack, k8s 両方のvmi が記載されていることを確認可能
まとめ
簡単だが、Tungsten Fabric のインストール方法についてまとめておいた。
これ以外に、ec2インスタンス作成、等も自動で実施する、cloud formationを使った仕組みも用意されている。
すぐに試したい場合には、こちらを使ってみてもよいのではなかろうか。
https://github.com/Juniper/contrail-ansible-deployer/wiki/Deployment-Example:-Click-On-Deployment-of-Contrail-and-Kubernetes-in-AWS
AWS上でのHA構成(k8s)
以下の文書に従い、Tungsten controller の 3-node 構成を試してみたので、その際のメモとなる。(k8sを使用)
https://github.com/Juniper/contrail-docker/wiki/Provision-Contrail-CNI-for-Kubernetes-with-High-Availability-(HA)
事前準備として、t2.large の ubuntu16.04.2 (メモリ8GB, ami-ea4eae8c) を5台用意し、kubeadm を使って master x 1, slave x 4 の構成を用意している.
詳しくは、以下のリンクを参照。
http://aaabbb-200904.hatenablog.jp/entry/2017/10/15/034243
その後、k8sの設定ファイルを環境に合わせて書き換え、kubectl apply で適用する。
修正内容として、以下のように、tungsten のcontroller, analytics, analyticsdb をデプロイするipを変更する、という内容となる。
# git clone https://github.com/Juniper/contrail-docker.git -b R4.0 # cd contrail-docker/kubernetes/manifests/ # vi contrail-host-ubuntu-ha.yaml (以下の行を修正) config_nodes = 10.84.24.52,10.84.24.53,10.84.14.144 controller_nodes = 10.84.24.52,10.84.24.53,10.84.14.144 analytics_nodes = 10.84.24.52,10.84.24.53,10.84.14.144 analyticsdb_nodes = 10.84.24.52,10.84.24.53,10.84.14.144 - api_server = 10.84.14.144
また、上記に加えて、tungsten の docker を起動したいslave ノードについては、以下を実行し、起動の許可を出す必要があるのだが、
# kubectl label node <node-name> opencontrail.org/controller=true
実機で試した時には、以下のエラーが発生したため、master ノードでパッケージのアップデートを行い、解消させるようにしている。
# kubectl label node 'ip-172-31-7-231' 'opencontrail.org/controller=true' The Node "ip-172-31-7-231" is invalid: metadata.labels: Invalid value: "opencontrail.org~1controller": name part must consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyName', or 'my.name', or '123-abc', regex used for validation is '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]') # # apt-get update kubectl # dpkg -l | grep -i kube ii kubeadm 1.7.4-00 amd64 Kubernetes Cluster Bootstrapping Tool ii kubectl 1.10.0-00 amd64 Kubernetes Command Line Tool ii kubelet 1.7.4-00 amd64 Kubernetes Node Agent ii kubernetes-cni 0.6.0-00 amd64 Kubernetes CNI # kubectl label node 'ip-172-31-7-231' 'opencontrail.org/controller=true' node "ip-172-31-7-231" labeled #
その後、以下のコマンドで DaemonSet の定義を行うと、約10分後に、container の起動が行われた。
# kubectl apply -f contrail-host-ubuntu-ha.yaml
上手く起動すると、以下のURLで、
http://contoller-ip:8080
で、webui にログイン可能となる。
※ id:pass は、 admin:contrail123
なお、こちらで試した際には、controller が起動した slave ノードでは vhost0 がうまく作られず、controller 以外の container が起動出来ない状態になってしまったのだが、一度 os のリブートを行うことで事象が解消し、webui からもvrouter として認識されるようになった。
※ 合わせて、念のため、各ノードで以下も実施している
# apt install ntp
