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社のブログでのアナウンス。

mesosphere.com

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とはなんだ

上記ブログの絵を引用しますが

https://mesosphere.com/wp-content/uploads/2017/08/mesosphere-dcos-kubernetes.png

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という話でしたがはたして。

f:id:jyoshise:20171218140532p:plain

こちらをデプロイしてみます。

f:id:jyoshise:20171218141312p:plain

このように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分ぐらいかかりました。 f:id:jyoshise:20171218153001p:plain

単純に各コンポーネントを起動しているだけではなく、kube-dns, heapster, dashboardといったadd-onを設定するジョブも走ります。

最初のひとつのタスク（上記の例で言うと kubernetes.509a7e81-e3b4-11e7-a0ee-9eaf3842cc33 ）はMarathon上のコンテナとして起動し、これをブートストラップとして、残りのタスクがMesosのFrameworkとして起動されます。Mesosから見るとこうなります。 f:id:jyoshise:20171218152623p:plain

この状態で、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以外のワークロードを共通のリソースプール上で動かしたい。たとえば
    • Kubernetes上のマイクロサービス
    • Cassandra、HDFSなどの分散データサービス
    • コンテナ化できないGPUワークロードとか

これは強力な動機になりえるんじゃないかと思います。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クラスタ自体をどう管理するか →ここが各社の腕の見せ所

なんじゃないかなーと思いつつ、どうだ忘年会が終わるまでに書き終えたぞ！みんなインフルエンザには気をつけろ！（３日遅れで失礼しました。）