帰ってきた（？）Stackato改めSUSE Cloud Application Platform
この記事は
Cloud Foundry Advent Calendar 2017 - Qiita
の23日目のエントリーです。間に合うか。
Last Christmas, I gave you my heart
去年のクリスマス、私は何をしていたかというとこんなのを書いてました。
Stackato4は本当に面白いプロダクトで、
- 当時まだ（今ほどは）メジャーになっていなかったKubernetesを大胆にコントロールプレーンとして採用
- 各種サービスをKubernetesのネームスペース上で管理
- 通常BOSHで仮想マシンレベルでデプロイされるCloud Foundryの各コンポーネントをコンテナ化してKubernetes上で実行
という、当時としてはかなりぶっ飛んだというか、時代の２歩ぐらい先を行っていたモノだったと思います。さらにKubernetesの下のレイヤーではOpenStackとも統合され、HeatがNeutron LB(Octavia)やCinderをKubernetes用に構成してくれました。今となってはふつうにできることではありますが。
私はkubectlを10万回ぐらい叩きながら、「うぉーこれがこれからの分散サービスプラットフォームの姿か」と思ったものでした。
But the very next day you gave it away
そんなStackatoをHPEは手放してしまいました。開発リソースはSUSEに引き継がれましたが、Stackatoは販売 糸冬 了。かくしてPivotal Cloud Foundryが唯一の商用Cloud Foundryディストリビューションとなりました。
ヤツが帰ってくる・・・のか？
SUSEは2017年にSUSE CaaS Platform (CaaSP)という名の、Kubernetesのエンタープライズ向けディストリビューションを発売しました。
これは「純粋な」KubernetesのクラスタをSaltを使って構成するというもので、HPEから引き継がれたHelion Control Plane（StackatoのKubernetes部分）とは全く別の実装となっています。現在ではKubernetes1.7ベースのV2.0がリリースされています。
そして2017年11月。シドニーでの（なぜか）OpenStack Summitで、SUSE Cloud Application Platform (CAP)が発表されました。
SUSE Cloud Application Platform | SUSE
下記の図はSUSEのblogからの転載ですが、
要するにSUSE CaaSP (Kubernetes)の上にコンテナ化されたCloud Foundryを載せたというディストリビューションに見えます。
Stackatoでは、Kubernetesの上にCloud Foundryだけではなく、CI/CDツール（ConcourceベースのHelion Code Engine）やデータサービス（MySQL、Postgresなど）も載っていましたが、そういったものはなさそうです。ふつうにKubernetes上にhelmとか使って構成してください、ということなのでしょう。
さて動かしてみよう
というわけで動かしてみようかと思ったのですが、SUSE CAPはまだリリースされておらず、ベータも入手できませんでした。が、SUSE Cloud Foundry (SCF)はオープンソースで開発されており、GitHubからソースコードとベータリリースを入手できます。
ということは、SUSE CaaSP 2.0（これは評価版ダウンロード可能です）の上に、OSSのSCFを展開すれば、SUSE CAPのベータっぽいものになるんではないか？ということで、試してみました。
だがしかし
SUSE CaaSPのドキュメントが、ベアメタルへのインストールを前提としており、しかもDVDを入れるところからというハードモードな展開で、いきなり断念しました。そんな何台もサーバ持ってませんって。
Suse Doc: Deployment Guide - Installing SUSE CaaS Platform - November 16 2013
ダウンロードできるイメージはDVDのISOの他にKVMやOpenStack用のQCOW2やHyper-V用のものもあったので、IaaS上へのデプロイも可能なんでしょうが、やり方がどこにも書いてませんでした。
仕方がないのでSCFだけでも
しょうがないのでAKSかDC/OSで動いているKubernetesの上にSCFをデプロイしようとしたのですが、
https://github.com/SUSE/scf#deploying-scf-on-kubernetes
に
After careful consideration of the difficulty of the current install, we decided not to detail the instructions to install on bare K8s because it still requires far too much knowledge of SCF related systems and troubleshooting.
Please be patient while we work on a set of Helm charts that will help people easily install on any Kubernetes.
と書いてありましたとさ。えー。
で、VagrantでローカルPC上にシングルノードKubernetes環境を作って、そこでSCFを動かす方法が書いてあったので、それを試してみました。
まずソースコードをダウンロードしろと
$ git clone --recurse-submodules https://github.com/SUSE/scf
ん、 --recurse-submodules ですか。。。もしかして fissile 使ってゼロからDockerイメージビルドする手順ってことですか。。。
まあいいや。OSSらしくていいじゃないですか。1時間近くかけてgit clone。
ビルドビルド
Vagrantfileも入っているので vagrant up するとシングルノードのKubernetesが上がってきます。
vagrant@vagrant-kube:~/scf> kubectl get nodes NAME STATUS ROLES AGE VERSION 127.0.0.1 Ready <none> 10m v1.8.4
で、 make vagrant-prep とするとDockerイメージのビルド、Helm Chartの作成が行われます。Core i7, メモリ16Gをフルに使って2時間ぐらいかかりましたので、ここは寝るとこです。翌朝目覚めると
vagrant@vagrant-kube:~/scf> docker images REPOSITORY TAG IMAGE ID CREATED SIZE splatform/uaa-mysql 2b79bdda86a441c39e90e6e2743834d6ed8a25fe 1e97f9c0f14a 7 hours ago 3.2 GB splatform/uaa-uaa d743ee771b1d5ddbf60f9acd5022b5e4ff47b582 a44c6b3da9a8 7 hours ago 3.2 GB splatform/uaa-secret-generation 46d409f7080d58367476a773c6c66ddde9b3f98b 0a63e5fb877b 7 hours ago 3.2 GB uaa-role-packages 6213179b3f9c0903db42c7ad9390f203871b1afe c8a0c3534c94 7 hours ago 3.2 GB splatform/scf-secret-generation a55a32c6d64fa9de0510336792fcb02a13cd2510 007ae398cc40 7 hours ago 6.781 GB splatform/scf-post-deployment-setup 7b25df7bae098f5ff259d2a370e1acaa4f8e6c2b bfdd5a328624 7 hours ago 6.781 GB splatform/scf-acceptance-tests defb68ce504472c73fc7589b9c0164cdc9574f5e a0f3784ddabc 7 hours ago 6.781 GB splatform/scf-smoke-tests d3055b8eb2ac356833757ec47de875bb47c07673 f3d0620917ad 7 hours ago 6.781 GB splatform/scf-acceptance-tests-brain 01e823895d97eb918a7276eb4b1b442cc48e32ad fc38d1dd4d77 7 hours ago 6.781 GB splatform/scf-diego-cell 82ed8025c021a7d1eac531204dbc1fe3269a6863 12591a847c56 7 hours ago 6.781 GB splatform/scf-nfs-broker 847a907e0a82515348ab307c7b1e7e7168cf61ef e0801950a17a 7 hours ago 6.781 GB splatform/scf-diego-access d0745225743b233ce40819d4fd2d0e3ec6385213 bbf9c7d14035 7 hours ago 6.781 GB splatform/scf-cc-uploader 5adf1d0e9b2ffb355793bf017cc57f76170dd1f6 85666eea772c 7 hours ago 6.781 GB splatform/scf-loggregator 98439bdbbd97e6209044c40b3411e04e8cd68d9e cf85f6dc71a3 7 hours ago 6.781 GB splatform/scf-diego-brain f8e02e2aa0ba9241a30c119aebf15fe1116e1e12 190160b08a0b 7 hours ago 6.781 GB splatform/scf-doppler f0c49f89a8b6083394eba73573ab2eaa3422ff2b 7bf78c32b852 7 hours ago 6.781 GB splatform/scf-cc-clock 35aed0de79491e69406dba042978e4aa818bf241 7368f088abfe 7 hours ago 6.781 GB splatform/scf-cc-worker bd5b07b58f2331dc6db8f781e08e3927e7e8f15b bff56502bd23 7 hours ago 6.781 GB splatform/scf-blobstore 02c3a328b26c0be009cfc899bd33ed9087790294 ec9dc6f464c9 7 hours ago 6.781 GB splatform/scf-api f5be5b8166a9c0efc8f20f66a803abb10ab1f01e b8acea8750b6 7 hours ago 6.781 GB splatform/scf-routing-api 2741864e80fae353aae7b74338bca72a021b92e5 aa48bb10665c 7 hours ago 6.781 GB splatform/scf-tcp-router 102ea409285ad34c313cdc014db2b68c04f564c3 93a5076834ed 7 hours ago 6.781 GB splatform/scf-diego-api eb51c6eaa324a35344a3debf0065f3905ab97b6f 836473c9c1f8 7 hours ago 6.781 GB splatform/scf-router a7d0daaa947812f817e2882a3e224afc814c77ad 9710c857f908 7 hours ago 6.781 GB splatform/scf-diego-locket 5b0240c35728ce0990f20b467700b8dea04adced 6f6f2a6407d9 7 hours ago 6.781 GB splatform/scf-cf-usb 7105951f303938552323e880301515c7d5ec256d 2e77448049d2 7 hours ago 6.781 GB splatform/scf-mysql caa428174f926b1f028557371114e2c0dde855d0 774c56099f7d 7 hours ago 6.781 GB splatform/scf-mysql-proxy 0da1a69e760c35036236ec94eb455127eeed7d37 9a96072009a7 7 hours ago 6.781 GB splatform/scf-syslog-scheduler 83c45a25e66a506b5705b278ece1e96cc344b9f1 4eb7ae77afbf 7 hours ago 6.781 GB splatform/scf-syslog-rlp 7c8efb17c21a60bcf16b1ea8f0761505fac4b17c a8f51fd49692 7 hours ago 6.781 GB splatform/scf-syslog-adapter 24d868865aedd6da58742a4607bacbac812d9952 a9bb5ccc7366 7 hours ago 6.781 GB splatform/scf-nats 24443c42c637aff34e93960eaa4cdb256f2bd7c3 6adb2f5468ee 7 hours ago 6.781 GB scf-role-packages 114a7f364a78112c23c4acaf3e927547d8eec1ed cdf4d393c9c3 7 hours ago 6.781 GB splatform/fissile-stemcell-opensuse 42.2-21.g0757523-29.55 826dc0eadd9a 7 days ago 1.755 GB gcr.io/kubernetes-helm/tiller v2.6.2 069459be335a 11 weeks ago 78.02 MB splatform/bosh-cli 39747e9d1fbc1d32af3672f903b6c4b73e1e1a9e 6b95889b110a 11 weeks ago 1.995 GB gcr.io/google_containers/k8s-dns-sidecar-amd64 1.14.1 fc5e302d8309 9 months ago 44.52 MB gcr.io/google_containers/k8s-dns-kube-dns-amd64 1.14.1 f8363dbf447b 9 months ago 52.36 MB gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64 1.14.1 1091847716ec 9 months ago 44.85 MB gcr.io/google_containers/pause-amd64 3.0 99e59f495ffa 19 months ago 746.9 kB
おー。できた。
いちおうこちらにはビルド済みのリリースっぽいものもあるので、これを使うと上記の手順は飛ばせるのかもしれません。
起動
あとは make run すれば、namespaceが作られ、helmチャートが走って、UAAとCloud Foundryがそれぞれのnamespace内で起動します。これは数分。
vagrant@vagrant-kube:~/scf> kubectl get pods --namespace cf NAME READY STATUS RESTARTS AGE api-0 1/1 Running 1 8m blobstore-0 1/1 Running 0 8m cc-clock-5c4c8fb74c-96n9t 1/1 Running 0 8m cc-uploader-5d7665c5d7-hhjqs 1/1 Running 0 8m cc-worker-6799fbf5c9-s5d94 1/1 Running 0 8m cf-usb-79577cd664-bsf4j 1/1 Running 0 8m diego-access-b54c65f9f-vw2xc 1/1 Running 0 8m diego-api-769fb4cf8c-247s5 1/1 Running 0 8m diego-brain-64f44b9f67-npnm8 1/1 Running 0 8m diego-cell-0 1/1 Running 0 8m diego-locket-9cc87ff78-g6dpq 1/1 Running 0 8m doppler-5ccc5746f9-v28p2 1/1 Running 0 8m loggregator-85f6cf876d-8zcqq 1/1 Running 0 8m mysql-0 1/1 Running 0 8m mysql-proxy-755b7dbfc7-6blw9 1/1 Running 0 8m nats-0 1/1 Running 0 8m nfs-broker-566564c64-zq582 1/1 Running 0 8m router-6cd48dd877-5lv67 1/1 Running 0 8m routing-api-0 1/1 Running 0 8m syslog-adapter-779759b677-j65f4 1/1 Running 0 8m syslog-rlp-755d7b8647-swnsr 1/1 Running 0 8m syslog-scheduler-c669995d-qmcxr 1/1 Running 0 8m tcp-router-77676b9d9-gn25j 1/1 Running 0 8m
vagrant@vagrant-kube:~/scf> cf api --skip-ssl-validation https://api.cf-dev.io
Setting api endpoint to https://api.cf-dev.io...
OK
API endpoint: https://api.cf-dev.io (API version: 2.99.0)
User: admin
Org: system
Space: No space targeted, use 'cf target -s SPACE'
vagrant@vagrant-kube:~/scf> cf login
API endpoint: https://api.cf-dev.io
Email> admin
Password>
Authenticating...
OK
Targeted org system
API endpoint: https://api.cf-dev.io (API version: 2.99.0)
User: admin
Org: system
Space: No space targeted, use 'cf target -s SPACE'
よろしい。ちゃんとCFだ。
さてこれはいいものなのか
まだ完成したディストリビューションとは言い難く、私もとりあえず起動してみただけなのでなんとも言えませんが、少なくとも以下は前向きに評価できるポイントかと思います。
- 少なくともBOSHリリースからfissileを使ってコンテナ化するところはちゃんとできているようだ。
- デプロイにHelmを使っている。つまり独自技術に頼らず、Kubernetesのエコシステムに乗っかることを前提としている。
- fissileも含めてオープンソースである。
- Pivotalの、BOSHを共通レイヤーとしてその上にPKS(Kubernetes) + PAS(Cloud Foundry)というコンセプトもよいが、それとは別のエッジが効いている。
個人的には
やはりふつうのKubernetesの上で動かしてみたいですね。あと、
特別なお客様限定でSUSE Cloud Application Platformのご提供を開始しました
ってありますがどこまで本気で商用展開しようとしているのかも気になります。
間に合った。メリークリスマス。
Mesosphere DC/OSがKubernetesと叫ぶ声が聞こえた
言い訳から入るのがいちばんダメなやつ
この記事は
Kubernetes Advent Calendar 2017 - Qiita
および
Mesos Advent Calendar 2017 - Qiita
の15日目・・・だったはずなのですが、インフルエンザB型を発症してしまいましてですね。死ぬかと思ったです。窓があったら飛び降りてたかもしれない。皆さんもお気を付けください。
そして今日は18日、メルカリ方面から流れてくるコアなみなさんの楽しげなツイートを眺めながらこの記事を書いています。くそう。
猫も杓子もKubernetesと言い出した2017年
さすがに杓子が言ってるのは聞いたことないけど猫はたまに言ってる。AWSもMicrosoftもCNCFのプラチナメンバーになり、PivotalもMesosphereも、しまいにゃDockerも「これからはKubernetesだよ」とかドヤ顔で言い出し、Oracleまで「おれもおれも」とかかぶせてくるという2017年でした。
今回取り上げるのは、そのなかでもMesosphere DC/OSです。こちらが10月に出たMesosphere社のブログでのアナウンス。
Kubernetesの公式Docにも載りました。
https://kubernetes.io/docs/getting-started-guides/dcos/
- 100%純粋なアップストリームのKubernetes！
- クリック１回でKubernetesクラスタが出来上がる！
- デフォでHAでセキュア！
- イケてるデータプラットフォームとKubernetesが共存できる！
だそうです。ほう。
ちなみにDC/OSではなく、素のMesosの上にFrameworkとしてKubernetesをデプロイする方法も案内されています。
https://kubernetes.io/docs/getting-started-guides/mesos/
もちろんこちらのほうが手間はかかります。
そもそもMesosphere DC/OSとはなんだ
上記ブログの絵を引用しますが
DC/OSという名前が示す通り、データセンターをひとつのOSにしてしまおうという野心に満ちたコンセプトであり、考え方としてはGoogleのBorgとか、AWSそのものに近いところを目指したアーキテクチャになっています。と思います。下回りのリソース管理はApache Mesosが行い、タスクのスケジューリングは各種Frameworkが行うという、Two-level Scheduling を特徴としています。
これまでDC/OS上でのコンテナオーケストレーターとしては、Mesosphere社自身が開発したMarathonがメインでしたが、そもそもMarathonもFrameworkのひとつでしかないため、別のFrameworkとしてKubernetesが併存するというのはアーキテクチャ的にはアリなわけです。
なにはともあれデプロイしてみましょう
DC/OSのサービスカタログ（Universe）に、beta-kubernetesというものがあります。まだbetaです。年内にGAという話でしたがはたして。
こちらをデプロイしてみます。
このようにGUIからも各種パラメーターを指定できるのですが、だるいのでJSONで書きます。ざっとこんな感じです。
{
"service": {
"name": "kubernetes",
"sleep": 1000,
"log_level": "INFO"
},
"kubernetes": {
"service_cidr": "10.100.0.0/16",
"node_count": 3,
"node_cpus": 2,
"node_mem": 2048,
"node_disk": 1024
},
"etcd": {
"count": 3,
"cpus": 0.5,
"mem": 1024,
"data_disk": 3072,
"wal_disk": 512,
"disk_type": "ROOT"
},
"scheduler": {
"count": 3,
"cpus": 0.5,
"mem": 512
},
"controllermanager": {
"count": 3,
"cpus": 0.5,
"mem": 512
},
"apiserver": {
"count": 3,
"cpus": 0.5,
"mem": 1024
},
"kube-proxy": {
"cpus": 0.1,
"mem": 128
}
}
基本的には各コンポーネントに対するリソース割当を指定すればOKです。上記は最低限のHA構成です。少なくともetcdは3ノードないとデプロイしてくれません。
JSONファイルを用意したらあとはコマンド一発でデプロイ開始です。
$ dcos package install beta-kubernetes --options=dcos_kubernetes.json
手元の環境では全部上がってくるのに10分ぐらいかかりました。
単純に各コンポーネントを起動しているだけではなく、kube-dns, heapster, dashboardといったadd-onを設定するジョブも走ります。
最初のひとつのタスク（上記の例で言うと kubernetes.509a7e81-e3b4-11e7-a0ee-9eaf3842cc33 ）はMarathon上のコンテナとして起動し、これをブートストラップとして、残りのタスクがMesosのFrameworkとして起動されます。Mesosから見るとこうなります。
この状態で、DC/OSクラスタの外からAPIを叩いたり kubectl を使うにはsshトンネルを掘る必要があります。
$ ssh -4 -N -L 9000:apiserver-insecure.kubernetes.l4lb.thisdcos.directory:9000 <user>@<DC/OSノードのどれか>
あとはふつうに
$ kubectl get nodes NAME STATUS AGE VERSION kube-node-0-kubelet.kubernetes.mesos Ready 5h v1.7.10 kube-node-1-kubelet.kubernetes.mesos Ready 5h v1.7.10 kube-node-2-kubelet.kubernetes.mesos Ready 5h v1.7.10
おー。
どんなもんか
現時点ではbetaですので、いろいろと制約があります。
https://docs.mesosphere.com/service-docs/beta-kubernetes/0.3.0-1.7.10-beta/limitations/
- One Kubernetes cluster per DC/OS cluster.
- One Kubernetes worker node per DC/OS agent.
のあたりは、まあそういうものだと割り切ればよいのですが
- Authorization mode is not configurable.
とか
- Horizontal Pod Autoscaling custom metrics are not available.
とか
- Package upgrades are not supported.
といったあたりは、やはりまだプロダクションで使えるものではなさそうです。正式リリースに期待。
こんな人は検討してみる価値はあるかも
- KubernetesとKubernetes以外のワークロードを共通のリソースプール上で動かしたい。たとえば
これは強力な動機になりえるんじゃないかと思います。AWSとかのパブリッククラウド上でk8sを動かすのであれば、データ系のサービスなんかはマネージドのものを使えばいいんですが、オンプレでそれをやろうとしたときに、SMACK Stackみたいなものが手軽に組めるDC/OSは強いです。
簡単ななんちゃってexampleですが、DC/OS上のKubernetesとCassandraを連携させる例が公開されてました。 dcos-kubernetes-quickstart/os-detector.md at master · mesosphere/dcos-kubernetes-quickstart · GitHub
あとは
- オンプレでKubernetesを組むにあたり、クラスタ自体の管理レイヤーがなにか欲しいけどOpenStackとか持ってないし
ってとこですかね。少なくともOpenStackを導入するよりはDC/OSを導入するほうが手軽ではあります。
これから
下回りのプラットフォームの選択肢が多いことはKubernetesのいいところですが、裏返すと、Kubernetesクラスタ自体をどうデプロイして管理するべきか、という問に対して（少なくともオンプレでは）ただひとつの答えというものはありません。
PivotalはそこにBOSHを持ってきましたね。これもおもしろいですね。 Cloud Foundry Container Runtimeでk8s運用 - Cloud Penguins
2018年は、各社からオンプレ/プライベート向けKubernetesのディストリビューションが出てくるんじゃないかと思います。そこでポイントになるのは
- Kubernetesの純粋さ →Forkは悪手ですよね。
- Kubernetesクラスタ自体をどう管理するか →ここが各社の腕の見せ所
なんじゃないかなーと思いつつ、どうだ忘年会が終わるまでに書き終えたぞ！みんなインフルエンザには気をつけろ！（３日遅れで失礼しました。）
いまさらブログかよ
なぜブログ
45年も生きてりゃブログのひとつやふたつの経験はあるんですが・・・あまり個人的に情報発信するってことは積極的にはやってなかったわけです。とはいえ仕事でいろいろイベントに登壇したりとか、コミュニティ的な活動なんかもあるわけで、Qiitaとか使ってたんですが、そうすると仕事なのか個人的な活動なのかって話になるわけで、めんどくせえからもう全部個人ってことでいいんじゃねえかと。はてブでいいんじゃねえかと。Qiitaにポエム書くと消されるそうですし。
ていうか
師走だなあ。僕は君といるときがいちばん師走なんだ。僕は死ぬまで君を離さないぞ。いいだろう？
というわけでアドベントカレンダーの季節でして、勢いで3つエントリーしてしまってました。
で順番迫ってきたので慌てて書く場所用意したってことです。はい。
