これはKubernetes Advent Calender 2016の12月24日のエントリです。23日のしんごちゃんのエントリはお楽しみいただけたでしょうか。本買ってあげてください。俺も買ったよ！まだ読んでないけど！
師走だなあ
メリークリスマス！ほーっほっほーう！笑ゥせぇるすまんぢゃないよ！ほーっほっほーう！
私はイタリア人のカトリック教徒ですので、家族と半日かけて黒トリュフのパスタと七面鳥の丸焼き等のディナーをプロセッコやモンテプルチアーノのワインと共にいただくのがいつものクリスマスイブの過ごし方なのですが（嘘です）、今年は長男が受験生のためクリスマスツリーすらありません（これは本当です）。そしてどうやらひどく酔っぱらっていたときにKubernetesのアドベントカレンダーにエントリーしていたようです。せっかくですので、**これがHPEの本気だ。Kubernetesを商用プライベートPaaSプロダクトにガチで取り込んだらこうなった！**をつまみに一杯やりましょう。
なお、このネタはCloud Foundry Days Tokyo 2016での発表でも一度取り上げてるのですが、Kubernetes（以下k8sと書きます）をどう使っているかを主眼にちょっとディープに行きたいと思います。ディープに！
ちょっとまてKubernetesでPaaSだと？
PaaSという言葉の定義自体もやっとしているのですが、k8sにアプリケーションコンテナのビルド等、開発フローをカバーする機能とエンタープライズ向けの管理機能を付加したものとして、RedHatのOpenShiftがあります。最近はRedHatさん自身あまりPaaSという言葉を前面に出さなくなってきたようですが（もやっとしてますからね）、k8sを機能強化してアプリケーションPaaSに仕立てたもの、と言ってよいと思います。詳しくは12月3日のエントリでnekopさんが紹介されています。私も触ってますが、コンテナプラットフォームとして痒いところに手が届く感じで、良いソリューションです1。
一方Cloud Foundryは、Pivotal,EMC,VMware,IBM,HPE,SAP,NTT,Fujitsu,GEといったいかにもエンタープライズな企業群が参加しているガチなOSS PaaSです。エンタープライズで揉まれてるだけあって、例えばRDBMSなどのバックエンドのサービスを利用するためのService Brokerが整備されていたり、またCertificationが厳密なので、例えばIBM Bluemixで動くアプリケーションコードはNTT CommunicationsのECLでも動く、といった互換性が保証されるなど、エコシステムにも一日の長があります。
k8sを擁するCNCFと、Cloud Foundryを擁するCFFの関係も興味深いところですが（こちらのインタビュー記事が面白かったです）、HPEがStackatoというCloud FoundryベースのPaaS製品をリニューアルするにあたり取った方針は以下のようなものです。
- k8sを共通のControl Planeとし、その上ですべてのサービスをContainerized Serviceとして管理する。
- Cloud Foundryそのものには手を付けずにコンテナ化し、Certificationのメリットを生かす。
- Control Plane(k8s)自体のデプロイはマルチIaaSに対応させる。
- HAはIaaSのAZとk8sのレイヤーで実現する。
これが製品としてリリースされたものがHPE Helion Stackato4です2。ポジショントークはダサいのでしませんが、技術的にいろいろ面白い実装がされていますので、Cloud Foundryに興味がない方でもそのアーキテクチャは参考になるのではと思います。
Helion Stackato4のアーキテクチャ概要
はい。前置きが長くなりましたが、Stackato4のアーキテクチャはこんな感じになっています。
はいなんだかよくわかんないですね。もうすこしざっくり書くとこんな感じです。
要するにすべてがコンテナとしてKubernetesの上で動くと。ただCloud Foundryは単純に（いやほんとは全然単純じゃないんですけど）各コンポーネントをコンテナ化しているだけで、中身の実装はUpstreamのCloud Foundryそのものなので、ユーザーアプリケーションのコンテナはDockerではなくDiegoで、そのオーケストレーションとスケジューリングもKubernetesから見えないところでCloud Foundry内部で行います。
KubernetesをContainerized Servicesの実行プラットフォームとして補完するための、Stackatoの主要なコアコンポーネントが以下になります。
- Helion Control Plane(HCP): IaaSと連携してk8sクラスタの管理をおこないます。HCP自体が後述のHSMで管理されるContainerized Serviceなので若干ややこしいですが。
- Helion Service Manager(HSM): k8s上で実行されるサービスを管理します。
- User Authorization and Authentication(UAA): 認証/認可を一元管理します。
TerraformでIaaS上にCore Servicesをデプロイ
bootstrapと呼ばれるインストーラーにより、まずIaaS上にk8sクラスタが構成され、その上にStackatoのCore ServiceであるHCPとHSMが構成されます。
まず設定ファイルに必要な情報を記述します。ノードの数とか
# REQUIRED. Sets the IaaS provider to use.
# Must be: OpenStack, AWS, VSphere, or local
Provider = OpenStack
# The number of container nodes to create during bootstrap.
# NOTE: NodeCount should be a multiple of No. of AZs/Clusters provided for IaaS
NodeCount = 3
# The number of master nodes to create during bootstrap.
MasterCount = 1
# The number of gluster nodes to create during bootstrap.
GlusterNodeCount = 2
IaaS固有の情報とか（こちらはOpenStackの例です）
# OpenStack Provider Configuration
OpenStack.CACertFile = /home/ubuntu/certs/ca-certificates.crt
OpenStack.AuthURL = https://192.0.111.104:5000/v3
OpenStack.Username = junichi
OpenStack.Password = password
OpenStack.DomainName = default
OpenStack.ProjectID = 5a3c84bd0ca3427f9d667925b6a1acc1
OpenStack.ProjectName = Stackato4
OpenStack.RegionName = region1
OpenStack.LinuxImageID = a61d07fb-4d95-4d7b-b87d-e77bfd37395e
OpenStack.MasterFlavorID = 3
OpenStack.NodeFlavorID = 5
OpenStack.GlusterFSFlavorID = 3
OpenStack.Keypair = stackato-key
OpenStack.KeypairFile = /home/ubuntu/stackato.key
OpenStack.JumpboxCIDR = 10.1.1.4/32
OpenStack.LoadBalancerCIDR = 10.1.1.0/24
OpenStack.NetworkID = a94493c3-2b5d-47a8-9f1c-1ba51b702ee9
OpenStack.SubnetID = 76b97588-bf91-46c0-bc0b-0f491404dfc8
OpenStack.FloatingIPPoolName = ext-net
OpenStack.FloatingIPPoolID = 178f8150-b016-46e8-af1f-0a9856dc3f74
OpenStack.AvailabilityZones = nova
そしてbootstrap install -i 設定ファイルと叩くとあとは待つだけなのですが、中で何が行われているかというと、Terraformくんが泣きながら靴屋の小人のような肉体労働をしています。
- bootstrapが設定ファイルを読み込み、Terraformのテンプレートファイルを生成します。
- TerraformがIaaSのAPIを叩いて、まずk8s Masterノード用に以下のリソースを確保します。
- セキュリティグループ
- Floating IPアドレス
- ブロックストレージボリューム
- コンピュートインスタンス（仮想マシン）：Ubuntuのイメージでブート
- k8s Masterノードに必要なコンポーネントをインストールし、k8sクラスタを立ち上げます。
- 残りのノード（k8s Nodes, Gluster Nodes）も同様にIaaSからリソースを確保し、必要なコンポーネントをインストールし、k8sクラスタに参加させます。
- k8sクラスタ上でHCPとHSMのPodを作成します（普通にdocker pullしまくります）。
- Neutron LBaaS（Octavia）を叩いて、HCPとHSMのAPIエンドポイント用のLoad Balancerを作成します。
LogstashなんかでOpenStackのログを眺めているとなんだか偉くなったような気がしてきます。
ちなみにOpenStack上に簡易的にk8sを構成する場合、CNCF公式？的には、OpenStackのオーケストレーションサービスであるHeatとSaltStackを使う方法が案内されています。16日のyuanyingさんのエントリでも触れられていますね。
Kubernetesはどんな感じで構成されてんの
今回は（財布の事情で）OpenStackの上にシングルAZ（非HA構成）で展開しています。
$ nova list --fields name,networks
+--------------------------------------+------------------------------------------------------------+---------------------------------------+
| ID | Name | Networks |
+--------------------------------------+------------------------------------------------------------+---------------------------------------+
| 5a791011-1def-4581-9492-79c0222c12bb | hcp-gluster-24eb2afe-c3a2-11e6-a143-fa163e7d9a3f | stackato-net=10.1.1.10 |
| 1e06ebff-545a-4eca-8e46-5e0b6a25bad5 | hcp-gluster-ea424bcb-c39f-11e6-a143-fa163e7d9a3f | stackato-net=10.1.1.9 |
| 925f639e-9159-4954-802a-eaadc3890708 | hcp-kubernetes-master-1a7ae212-c398-11e6-a143-fa163e7d9a3f | stackato-net=10.1.1.5, 15.210.189.134 |
| a1057f25-c20f-4b6c-8fce-2f6f16025c0f | hcp-kubernetes-node-34651767-c39d-11e6-a143-fa163e7d9a3f | stackato-net=10.1.1.7, 15.210.189.154 |
| 9b82bce5-0b42-4c7f-8f31-3055cb268e00 | hcp-kubernetes-node-b26fe7b6-c39e-11e6-a143-fa163e7d9a3f | stackato-net=10.1.1.8, 15.210.189.155 |
| 03f3fffb-8171-49fc-8db3-f262116bacdc | hcp-kubernetes-node-b69d3e96-c399-11e6-a143-fa163e7d9a3f | stackato-net=10.1.1.6, 15.210.189.152 |
| 8bd48abd-eec3-4697-9fdc-3472061caeee | stackato-jump | stackato-net=10.1.1.4, 15.210.189.169 |
+--------------------------------------+------------------------------------------------------------+---------------------------------------+
stackato-jumpというインスタンスはインストーラを動かしたりする踏み台サーバです。
Kubernetes側からみるとこうなります。
ubuntu@hcp-kubernetes-master-1a7ae212-c398-11e6-a143-fa163e7d9a3f:~$ kubectl get nodes
NAME STATUS AGE
hcp-gluster-24eb2afe-c3a2-11e6-a143-fa163e7d9a3f Ready,SchedulingDisabled 6d
hcp-gluster-ea424bcb-c39f-11e6-a143-fa163e7d9a3f Ready,SchedulingDisabled 6d
hcp-kubernetes-master-1a7ae212-c398-11e6-a143-fa163e7d9a3f Ready,SchedulingDisabled 6d
hcp-kubernetes-node-34651767-c39d-11e6-a143-fa163e7d9a3f Ready 6d
hcp-kubernetes-node-b26fe7b6-c39e-11e6-a143-fa163e7d9a3f Ready 6d
hcp-kubernetes-node-b69d3e96-c399-11e6-a143-fa163e7d9a3f Ready 6d
Masterはひとつにしてますがもちろん複数にできますし、IaaSを3AZ構成にして
こんな形でHA構成を組んでSPOFをなくすことも可能です。AWSの場合は同一リージョン（VPC）内の3AZ、VMwareの場合は同一DataCenter内の3Clusterとなりますが、まあ考え方はおなじです。
あとnodeの追加/削除もコマンド一発でできますので、例えばHost OSのバージョンアップとかも1ノード追加→1ノード削除を繰り返せば楽勝です。
初期インストールを行った時点でのpodはこんな感じ
ubuntu@hcp-kubernetes-master-1a7ae212-c398-11e6-a143-fa163e7d9a3f:~$ kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
hcp flightrecorder-0-104838510-9fuzt 1/1 Running 0 6d
hcp heapster-0-4124770725-waeio 1/1 Running 0 6d
hcp hsm-server-0-656419251-y1rgb 1/1 Running 0 6d
hcp ident-api-0-1858970351-s96lk 1/1 Running 0 6d
hcp ipmgr-0-4012620876-qmy3r 1/1 Running 0 6d
hcp nats-0-3181689134-08d6j 1/1 Running 0 6d
hcp nats-1-4246649136-812pn 1/1 Running 0 6d
hcp nats-2-1017624882-b3g3c 1/1 Running 0 6d
hcp pgpool2-0-3727409503-ymct4 1/1 Running 0 6d
hcp pgsql-0-999819696-l8ej2 1/1 Running 0 6d
hcp pgsql-1-2738227635-kmdpa 1/1 Running 0 6d
hcp pgsql-2-182651318-swk5g 1/1 Running 0 6d
hcp rpmgr-0-3895479652-md9yu 1/1 Running 3 6d
kube-system kube-dns-v19-ew6f2 3/3 Running 0 6d
kube-system logging-daemon-e4cqw 1/1 Running 0 6d
kube-system logging-daemon-exxlw 1/1 Running 1 6d
kube-system logging-daemon-f4ug9 1/1 Running 1 6d
kube-system logging-daemon-jaj9n 1/1 Running 0 6d
kube-system logging-daemon-ml59a 1/1 Running 0 6d
kube-system logging-daemon-wd97c 1/1 Running 0 6d
hcpというnamespaceで動いているのがStackatoのCore Serviceです。
k8sでいうところのservicesを見ると
ubuntu@hcp-kubernetes-master-1a7ae212-c398-11e6-a143-fa163e7d9a3f:~$ kubectl get services --namespace=hcp
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
flightrecorder-0-int 172.16.245.23 <none> 514/TCP,514/UDP 6d
flightrecorder-int 172.16.19.45 <none> 514/TCP,514/UDP 6d
heapster-0-int 172.16.210.127 <none> 443/TCP 6d
heapster-int 172.16.167.76 <none> 443/TCP 6d
hsm-server 172.16.67.32 10.1.1.13,15.... 443/TCP 6d
hsm-server-0 172.16.239.240 <none> 443/TCP 6d
ident-api 172.16.13.224 10.1.1.15,15.... 443/TCP 6d
ident-api-0 172.16.47.97 <none> 443/TCP 6d
ipmgr 172.16.214.163 10.1.1.11,15.... 443/TCP 6d
ipmgr-0 172.16.145.4 <none> 443/TCP 6d
nats-0-int 172.16.44.221 <none> 4222/TCP,6222/TCP,8222/TCP 6d
nats-1-int 172.16.29.18 <none> 4222/TCP,6222/TCP,8222/TCP 6d
nats-2-int 172.16.5.211 <none> 4222/TCP,6222/TCP,8222/TCP 6d
nats-int 172.16.36.91 <none> 4222/TCP,6222/TCP,8222/TCP 6d
pgpool2-0-int 172.16.42.3 <none> 9999/TCP 6d
pgpool2-int 172.16.231.15 <none> 9999/TCP 6d
pgsql-0-int 172.16.225.56 <none> 5432/TCP 6d
pgsql-1-int 172.16.110.82 <none> 5432/TCP 6d
pgsql-2-int 172.16.34.216 <none> 5432/TCP 6d
pgsql-int 172.16.214.105 <none> 5432/TCP 6d
rpmgr-0-int 172.16.9.46 <none> 8112/TCP 6d
rpmgr-int 172.16.89.61 <none> 8112/TCP 6d
となってまして、172.16.0.0/16はflannel networkですね。APIエンドポイントを持っているHSM（hsm-server）、UAA（ident-api）、HCP（ipmgr）にはLoad BalancerのExternal IPが割り当たっています。
Load BalancerはOpenStackのNeutron LBaaSを使ってますので、見てみると
$ neutron lbaas-loadbalancer-list
+--------------------------------------+----------------------------------+-------------+---------------------+----------+
| id | name | vip_address | provisioning_status | provider |
+--------------------------------------+----------------------------------+-------------+---------------------+----------+
| 0b58ab83-2849-410e-acd7-8573c44ab05e | aa1c0d4d8c3a411e6b9c3fa163e45240 | 10.1.1.11 | ACTIVE | octavia |
| eea957b5-f91e-4bb2-8a22-dacc5828742d | aa2b589f3c3a411e6b9c3fa163e45240 | 10.1.1.15 | ACTIVE | octavia |
| feeb793a-76c8-4169-8b4d-3245bb8844fb | aa423f0a5c3a411e6b9c3fa163e45240 | 10.1.1.13 | ACTIVE | octavia |
+--------------------------------------+----------------------------------+-------------+---------------------+----------+
とちゃんと作られてます。10.1.1.0/24はOpenStack Tenantのプライベートネットワーク（vxlan）、15.x.x.x がFloating IPです3。
Service ManagerによるConteinerized Serviceの配備と管理
Core Servicesがk8s上で動いてしまえば、あとはCloud Foundry他もろもろサービスを立ち上げていくだけです。あらかじめ用意されているサービスカタログはこちらになります。
ubuntu@stackato-jump:~$ hsm list-services
ID NAME PRODUCT VERSIONS CATEGORIES LABELS
stackato.hpe.havenondemand havenondemand 1.0 Analytics HPE HavenOnDemand
stackato.hpe.hce hce 4.0.0, 4.0.1 Platform Services Helion Code Engine
stackato.hpe.hcf hcf 4.0.0, 4.0.1 Platform Services Helion Cloud Foundry
stackato.hpe.hcp hcp 4.0.0, 4.0.1, 4.0.2 Platform Services Helion Control Plane
stackato.hpe.hsc hsc 4.0.0, 4.0.1 Platform Services Helion Console
stackato.hpe.mongo mongo 3.0 Data MongoDB, Dev Grade
stackato.hpe.mssql mssql 2014 Data Microsoft® SQL Server® 2014, Connector
stackato.hpe.mysql mysql 5.5 Data MySQL, Dev Grade
stackato.hpe.pass-through pass-through 1.0 Integration Generic Connector
stackato.hpe.postgres postgres 9.4 Data Postgres, Dev Grade
stackato.hpe.rabbitmq rabbitmq 3.6 Messaging RabbitMQ, Dev Grade
stackato.hpe.rds-mysql rds-mysql 5.5 Data AWS, Connector, MySQL
stackato.hpe.rds-postgres rds-postgres 9.4 Data AWS, Connector, PostGres
stackato.hpe.redis redis 3.0 Data Redis, Dev Grade
サービスのPodの構成やDocker Imageのロケーションなど、もろもろ必要な情報はSDL（たぶんService Definition Language）というもので定義されています。それとユーザが指定できる設定（IDL：たぶんInstance Definition Language）でサービスインスタンスが構成されます。
hcfってやつが目玉のCloud Foundryなのですが、これ超重量級なので、まずはちっちゃめのサービス(mysql)を上げてみます。
ubuntu@stackato-jump:~$ hsm create-instance stackato.hpe.mysql 5.5
IDLはJSONで指定することもできますが、指定しなければ必須の項目はインタラクティブに聞かれます。
サービスインスタンスの作成はipmgrというpodが行っていますので、何が行われているかはこのpodのログを眺めていると見えます。
$ kubectl logs -f ipmgr-0-4012620876-qmy3r --namespace hcp
ログががーっと流れて
time="2016-12-23T14:59:10Z" level=info msg="Service Defintion not available in the database. Downloading from catalog.."
time="2016-12-23T14:59:13Z" level=info msg="Updating instance state to creating"
time="2016-12-23T14:59:13Z" level=info msg="Converting instance into scheduler model"
time="2016-12-23T14:59:13Z" level=debug msg="Generating Kubernetes objects for 1 instances of mysql"
time="2016-12-23T14:59:13Z" level=debug msg="Generated Service: mysql-0-int"
time="2016-12-23T14:59:13Z" level=debug msg="Generated Service: mysql-int"
time="2016-12-23T14:59:13Z" level=info msg="Creating pod in zone {region1 nova}"
time="2016-12-23T14:59:13Z" level=debug msg="Minimum RAM: 512"
time="2016-12-23T14:59:13Z" level=debug msg="Maximum RAM: 5120"
time="2016-12-23T14:59:13Z" level=debug msg="VCPU checks are disabled, otherwise this component would use 0.200000 minimum, and 4.000000 maximum"
time="2016-12-23T14:59:13Z" level=debug msg="Generated deployment: mysql-0"
time="2016-12-23T14:59:13Z" level=debug msg="Generated PersistentVolumeClaim: mysql-mysql-volume-0"
time="2016-12-23T14:59:13Z" level=debug msg="Generating Kubernetes objects for 1 instances of hsm-side-car"
time="2016-12-23T14:59:13Z" level=debug msg="Generated Service: hsm-side-car-0-int"
・・・
- Cinder Volumeの作成
- k8s Persistent Volumeの作成
- Docker ImageのPull
- Podの作成
- LBの作成
といったことが行われます。
出来上がると、サービスごとにnamespaceが作られてPodが動きます。
$ kubectl get pods --namespace mysql
NAME READY STATUS RESTARTS AGE
hsm-side-car-0-3466768465-q6rvs 1/1 Running 0 37m
mysql-0-2603552991-9g4gd 1/1 Running 0 37m
これってCaaSなのかな
ここまでで、k8sをベースにContainerized Serviceを管理するプラットフォームということで、まあCaaSと言っていいんじゃないでしょうかね。
これがContainerized Cloud Foundryだ
Cloud FoundryもHSMで管理するサービスですので、デプロイはコマンド一発です。
$ hsm create-instance stackato.hpe.hcf 4.0.1
ただしCloud Foundry自体コンポーネントがものすごくたくさんあって、それがすべてコンテナ（Pod）になっているので、けっこう時間がかかります。またLoad BalancerのListenerも大量に作らなければならないので、そこも時間がかかるところです。といっても1時間ぐらい待っていればよいわけですから、Cloud FoundryをBOSHで構築する苦労に比べたらだいぶましなんじゃないかと。
Stackatoのために作成されたDocker Imageは公開されていませんが、Cloud FoundryのBOSHリリースからDocker Imageを作成するツールについてはFissileというオープンソースプロジェクトで開発されています。また、Cloud Foundryを一つのコンテナで動かすというオープンソースプロジェクト（cf-solo）もあります。
非HAの最小構成でもPodはこんだけあります。
$ kubectl get pods --namespace hcf
NAME READY STATUS RESTARTS AGE
api-0-1269602844-eekjd 1/1 Running 0 6d
api-worker-0-3021621250-7g2eh 1/1 Running 0 6d
blobstore-0-1045347869-o9l64 1/1 Running 0 6d
cf-usb-0-3174808792-56hcr 1/1 Running 0 6d
clock-global-0-2412693212-kiqbp 1/1 Running 0 6d
consul-0-79712408-o3y0z 1/1 Running 0 6d
couchdb-0-318207774-zuokq 1/1 Running 0 6d
demophon-0-1229856128-t6klg 1/1 Running 0 6d
diego-access-0-2226539070-8d8hr 1/1 Running 0 6d
diego-brain-0-3908308113-bddlx 1/1 Running 0 6d
diego-cc-bridge-0-4194499860-ezb0m 1/1 Running 0 6d
diego-cell-0-256593782-ar0cu 1/1 Running 0 6d
diego-database-0-4263788929-sxczv 1/1 Running 0 6d
diego-route-emitter-0-319234317-8h2q7 1/1 Running 0 6d
doppler-0-2666809206-n7jru 1/1 Running 0 6d
etcd-0-1260430302-0x0kc 1/1 Running 0 6d
hcf-sso-0-2052224978-i5ww6 1/1 Running 0 6d
hcf-versions-0-3802557632-fielb 1/1 Running 0 6d
loggregator-0-45371364-gqaow 1/1 Running 0 6d
mysql-0-3466069357-a2fff 1/1 Running 0 6d
mysql-proxy-0-1209629331-05xg5 1/1 Running 0 6d
nats-0-1760294884-cclna 1/1 Running 0 6d
router-0-2350743392-ga2ck 1/1 Running 0 6d
routing-api-0-3201920731-qt4qn 1/1 Running 0 6d
routing-ha-proxy-0-2233638232-4dlsr 1/1 Running 0 6d
sclr-api-0-701938043-7s8rf 1/1 Running 0 6d
sclr-broker-0-1069346724-3lequ 1/1 Running 0 6d
sclr-server-0-1809753673-sfkh3 1/1 Running 0 6d
Serviceもえらいことになってます。
$ kubectl get services --namespace hcf
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
api-0-int 172.16.15.140 <none> 9022/TCP,8125/TCP 7d
api-int 172.16.19.224 <none> 9022/TCP,8125/TCP 7d
blobstore-0-int 172.16.70.192 <none> 8080/TCP,4443/TCP 7d
blobstore-int 172.16.246.185 <none> 8080/TCP,4443/TCP 7d
cf-usb-0-int 172.16.191.8 <none> 24054/TCP,24053/TCP 7d
cf-usb-int 172.16.31.130 <none> 24054/TCP,24053/TCP 7d
consul-0-int 172.16.16.117 <none> 8300/TCP,8301/TCP,8301/UDP,8302/TCP,8302/UDP,8400/TCP,8500/TCP 7d
consul-int 172.16.20.47 <none> 8300/TCP,8301/TCP,8301/UDP,8302/TCP,8302/UDP,8400/TCP,8500/TCP 7d
couchdb-0-int 172.16.250.72 <none> 5984/TCP 7d
couchdb-int 172.16.224.178 <none> 5984/TCP 7d
demophon-0-int 172.16.128.201 <none> 8443/TCP 7d
demophon-int 172.16.237.145 <none> 8443/TCP 7d
diego-access 172.16.81.34 10.1.1.19,15.... 2222/TCP 7d
diego-access-0 172.16.218.76 <none> 2222/TCP 7d
diego-access-0-int 172.16.71.84 <none> 8080/TCP 7d
diego-access-int 172.16.8.220 <none> 8080/TCP 7d
diego-brain-0-int 172.16.184.231 <none> 9016/TCP 7d
diego-brain-int 172.16.186.200 <none> 9016/TCP 7d
diego-cc-bridge-0-int 172.16.37.69 <none> 8787/TCP,17006/TCP,17007/TCP,17011/TCP,8888/TCP,1518/TCP,17014/TCP,17015/TCP,9090/TCP,17018/TCP 7d
diego-cc-bridge-int 172.16.169.55 <none> 8787/TCP,17006/TCP,17007/TCP,17011/TCP,8888/TCP,1518/TCP,17014/TCP,17015/TCP,9090/TCP,17018/TCP 7d
diego-database-0-int 172.16.174.130 <none> 5678/TCP,8889/TCP,17017/TCP 7d
diego-database-int 172.16.178.222 <none> 5678/TCP,8889/TCP,17017/TCP 7d
doppler-0-int 172.16.246.89 <none> 3456/TCP,3457/TCP,3458/TCP 7d
doppler-int 172.16.227.16 <none> 3456/TCP,3457/TCP,3458/TCP 7d
etcd-0-int 172.16.53.29 <none> 4001/TCP,7001/TCP 7d
etcd-int 172.16.205.141 <none> 4001/TCP,7001/TCP 7d
hcf-sso-0-int 172.16.192.37 <none> 3000/TCP 7d
hcf-sso-int 172.16.97.19 <none> 3000/TCP 7d
hcf-versions-0-int 172.16.220.120 <none> 3000/TCP 7d
hcf-versions-int 172.16.23.154 <none> 3000/TCP 7d
loggregator-0-int 172.16.142.115 <none> 8080/TCP,8081/TCP 7d
loggregator-int 172.16.77.12 <none> 8080/TCP,8081/TCP 7d
mysql-0-int 172.16.198.22 <none> 3306/TCP,4567/TCP,4567/UDP,4568/TCP,9200/TCP,4444/TCP 7d
mysql-int 172.16.46.131 <none> 3306/TCP,4567/TCP,4567/UDP,4568/TCP,9200/TCP,4444/TCP 7d
mysql-proxy-0-int 172.16.218.150 <none> 3306/TCP,80/TCP,1936/TCP 7d
mysql-proxy-int 172.16.46.186 <none> 3306/TCP,80/TCP,1936/TCP 7d
nats-0-int 172.16.166.175 <none> 4222/TCP,4223/TCP 7d
nats-int 172.16.83.53 <none> 4222/TCP,4223/TCP 7d
router 172.16.66.243 10.1.1.17,15.... 80/TCP,443/TCP,4443/TCP 7d
router-0 172.16.221.235 <none> 80/TCP,443/TCP,4443/TCP 7d
routing-api-0-int 172.16.188.150 <none> 3000/TCP 7d
routing-api-int 172.16.128.138 <none> 3000/TCP 7d
routing-ha-proxy 172.16.45.80 10.1.1.21,15.... 2341/TCP,20000/TCP,20001/TCP,20002/TCP,20003/TCP,20004/TCP,20005/TCP,20006/TCP,20007/TCP,20008/TCP 7d
routing-ha-proxy-0 172.16.0.143 <none> 2341/TCP,20000/TCP,20001/TCP,20002/TCP,20003/TCP,20004/TCP,20005/TCP,20006/TCP,20007/TCP,20008/TCP 7d
sclr-api-0-int 172.16.240.89 <none> 28861/TCP 7d
sclr-api-int 172.16.68.61 <none> 28861/TCP 7d
sclr-broker-0-int 172.16.114.139 <none> 28863/TCP 7d
sclr-broker-int 172.16.109.63 <none> 28863/TCP 7d
sclr-server-0-int 172.16.150.88 <none> 28862/TCP 7d
sclr-server-int 172.16.199.25 <none> 28862/TCP 7d
ただCloud Foundry自体がrouterとhaproxyを持っているので、External IPを持っているサービスは3つだけです。
Cloud Foundry自体はCertifiedなものなので、DNSを設定すればあとはcf CLIで普通に使えます。
ubuntu@stackato-jump:~$ cf api https://api.hcf.stackato4.local --skip-ssl-validation
Setting api endpoint to https://api.hcf.stackato4.local...
OK
API endpoint: https://api.hcf.stackato4.local (API version: 2.63.0)
Not logged in. Use 'cf login' to log in.
ubuntu@stackato-jump:~$ cf login -u admin
API endpoint: https://api.hcf.stackato4.local
Password>
Authenticating...
OK
API endpoint: https://api.hcf.stackato4.local (API version: 2.63.0)
User: admin
No org or space targeted, use 'cf target -o ORG -s SPACE'
このアーキテクチャのなにがうれしいか
k8sの上のContainerized ServiceとしてCloud Foundryを動かすメリットは以下のようなものだと言えると思います。
- PaaSとCaaSを同居させることができる
- 複雑なCloud Foundryのデプロイが楽に行える
- CFのHA機能はBOSHによって実現されているが、それをk8sとIaaSのレイヤーで実現できるのでその点ではBOSHは不要
- CF自体のローリングアップグレードなどもk8sの機能を利用して行える
k8sがエンタープライズ向け製品の下回りを支えるに足る、信頼できるものになっているということですな。
これまではコンテナのユースケースというとどちらかというとWebのフロント周りとかのほうが多かったんじゃないかと思いますが、Cloud Foundryの他にも、OpenStackをk8sの上で動かすKollaなど、分散型アーキテクチャの個々のコンポーネントをコンテナ化してk8sの上で動かすというのはこれから流行るんじゃないかなと思います。
長くなっちゃいましたが
年明けのKubernetes Meetupでは、気になるネットワーク回りとか、実際の動きのデモ含めてもう少しご紹介したいと思います。
明日のクリスマスデーは大トリ、@Ladicleさんです。お楽しみに。
メリークリスマス！良いお年を！ほーっほっほーう！
-
HPEにとってRedHatは競合ではなくてパートナーですので、OpenShiftベースでのPrivate PaaS導入サービスなんかもデリバリしますよ。 ↩
-
現時点でStackato4の主要機能はKubernetesをはじめとするOSSで実現されていますが、Stackato4のすべてのソースコードが公開されているわけではありません。ちなみにHPEとMicroFocusおよびSUSEとのspin mergerにより、HPEに在籍していたCloud FoundryのContributorおよび関連知財はSUSEに移管されつつあります。そこには現時点でソースコードを公開していないHelion Control Planeなども含まれます。SUSEはご存知の通りOSS centricな会社であり、今後はCloud Foundryコミュニティと同時にKubernetesコミュニティへの注力も表明しています。ということは・・・言わせんな☆ ↩
-
余談ですが弊社は15.0.0.0/8と16.0.0.0/8を持ってまして正直スイマセン。 ↩