guestbook exampleをネタにオブジェクト定義を読み解く

このエントリはKubernetesアドベントカレンダー2014の12日目です。

今日はguestbook exampleを読み解いてみます。

guestbook example

Kubernetesに用意されているサンプルです。

このような構成になっています。

guestbook-overview

……なんとかならんのか、という感じですね。。。

Kubernetesのguestbook exampleでは Service が介在することで以下のようにすっきり構成させています。(frontendのserviceを作らない場合)

guestbook-kubernetes

定義していく順番はデータの流れの最奥・矢印の一番後ろからになります。

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 )のID
  • kind : このオブジェクトの種類( 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行目の portcontainerPort で、 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 らしい項目は replicasreplicaSelector ですね。 ここでは "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

  • ContainerLivenessProbe : 死活監視が HTTPGet|TCPSocket|Exec でできそうな感じ
  • ContainerImagePullPolicy : PullAlways|PullNever|PullIfNotPresent 。デフォルトは PullIfNotPresent で、イメージ指定に :latest タグがあれば PullAlways
  • VolumeSourceGitRepo : gitのリポジトリをチェックアウトしてくれるようです

ここまでくれば、できること・できないこともだいたいわかりましたね。 ご活用ください。


See also