このエントリはKubernetesアドベントカレンダー2014の12日目です。
今日はguestbook exampleを読み解いてみます。
guestbook example
Kubernetesに用意されているサンプルです。
このような構成になっています。
……なんとかならんのか、という感じですね。。。
Kubernetesのguestbook exampleでは Service
が介在することで以下のようにすっきり構成させています。(frontendのserviceを作らない場合)
定義していく順番はデータの流れの最奥・矢印の一番後ろからになります。
guestbookの例ではjsonを読み込んでいますが、 同じスキーマのyamlにも対応しているので人間が書くならyamlのほうがよさそうです。
1. redis(master)
というわけでまずは図の(a)を定義します。
9日目でこの操作で定義したものです。
kubectl create -f /opt/kubernetes/examples/guestbook/redis-master.json pods -s http://172.16.1.1:8080
kubectl create -f /opt/kubernetes/examples/guestbook/redis-master-service.json services -s http://172.16.1.1:8080
redis(master)のPod定義
{
"id": "redis-master",
"kind": "Pod",
"apiVersion": "v1beta1",
"desiredState": {
"manifest": {
"version": "v1beta1",
"id": "redis-master",
"containers": [{
"name": "master",
"image": "dockerfile/redis",
"cpu": 100,
"ports": [{
"containerPort": 6379,
"hostPort": 6379
}]
}]
}
},
"labels": {
"name": "redis-master"
}
}
それぞれの項目の意味は以下のとおりです。
id
: このオブジェクト(Pod
もしくはService
もしくはReplicationController
)のIDkind
: このオブジェクトの種類(Pod
もしくはService
もしくはReplicationController
)apiVersion
: コードを見ると、今のところv1beta3
まであるようですdesiredState
: このオブジェクトのあるべき状態Pod
ならコンテナの定義などReplicationController
なら並列数の定義も
labels
: このオブジェクト(今回はPod
)に付与するラベル
desiredState
以下の manifest
はGKEのcontainer manifestにsyntaxが書いてあります。
Container-optimized Google Compute Engine images - Google Compute Engine — Google Cloud Platform
なおguestbook exampleでは1Pod1種コンテナですが、複数コンテナをまとめることができます。
redis(master)のService定義
{
"id": "redis-master",
"kind": "Service",
"apiVersion": "v1beta1",
"port": 6379,
"containerPort": 6379,
"selector": {
"name": "redis-master"
},
"labels": {
"name": "redis-master"
}
}
5,6行目の port
と containerPort
で、
Service
がどのポートでデータを受け取り、
それを配下のコンテナのどのポートに流すか定義します。
7行目からの selector
で、配下のコンテナが何かを指定します。
10行目からの labels
で、このオブジェクト( Service
)に Pod
と同じラベルを付与しています。
わかりづらいですね。
2. redis(slave)
次は図の(b)を定義します。
9日目でこの操作で定義したものです。
kubectl create -f /opt/kubernetes/examples/guestbook/redis-slave-controller.json create replicationControllers -s http://172.16.1.1:8080
kubectl create -f /opt/kubernetes/examples/guestbook/redis-slave-service.json create services -s http://172.16.1.1:8080
redis(slave)のPod定義
ReplicationController
定義の中でPodを定義しています。
{
"id": "redisSlaveController",
"kind": "ReplicationController",
"apiVersion": "v1beta1",
"desiredState": {
"replicas": 2,
"replicaSelector": {"name": "redisslave"},
"podTemplate": {
"desiredState": {
"manifest": {
"version": "v1beta1",
"id": "redisSlaveController",
"containers": [{
"name": "slave",
"image": "brendanburns/redis-slave",
"cpu": 200,
"ports": [{"containerPort": 6379, "hostPort": 6380}]
}]
}
},
"labels": {
"name": "redisslave",
"uses": "redis-master",
}
}},
"labels": {"name": "redisslave"}
}
ReplicationController
らしい項目は replicas
と replicaSelector
ですね。
ここでは "name": "redisslave"
というラベルが付与されたオブジェクトを2並列で動かすように定義しています。
そして ReplicationController
にも "name": "redisslave"
というラベルを付与しています。
ラベルに "uses": "redis-master"
とありますが、特に動作には影響していない、ように見えます(たぶん)。
メモとして依存関係を記述しているもよう。
redis(slave)のService定義
{
"id": "redisslave",
"kind": "Service",
"apiVersion": "v1beta1",
"port": 6379,
"containerPort": 6379,
"labels": {
"name": "redisslave"
},
"selector": {
"name": "redisslave"
}
}
Service
定義はredis(master)とほぼ同じですね。
3. frontend
次は図の(c)を定義します。
9日目でこの操作で定義したものです。
kubectl create -f /opt/kubernetes/examples/guestbook/frontend-controller.json create replicationControllers -s http://172.16.1.1:8080
redis(master), redis(slave)と比較して特に目新しいものはないです。
guestbookで使っていない項目
どうもこのjson/yamlの定義が見当たらないのですが、コードを見るとなかなか興味深い項目があります。 ご活用ください。
kubernetes/types.go at master · GoogleCloudPlatform/kubernetes
Container
のLivenessProbe
: 死活監視がHTTPGet|TCPSocket|Exec
でできそうな感じContainer
のImagePullPolicy
:PullAlways|PullNever|PullIfNotPresent
。デフォルトはPullIfNotPresent
で、イメージ指定に:latest
タグがあればPullAlways
VolumeSource
のGitRepo
: gitのリポジトリをチェックアウトしてくれるようです
ここまでくれば、できること・できないこともだいたいわかりましたね。 ご活用ください。