示例：使用 Stateful Sets 部署 Cassandra

目录

下文描述了在 Kubernetes 上部署一个云原生Cassandra 的过程。当我们说云原生时，指的是一个应用能够理解它运行在一个集群管理器内部，并且使用这个集群的管理基础设施来帮助实现这个应用。特别的，本例使用了一个自定义的 Cassandra SeedProvider 帮助 Cassandra 发现新加入集群 Cassandra 节点。

本示例也使用了Kubernetes的一些核心组件：

准备工作

本示例假设你已经安装运行了一个 Kubernetes集群（版本 >=1.2），并且还在某个路径下安装了 kubectl 命令行工具。请查看 getting started guides 获取关于你的平台的安装说明。

本示例还需要一些代码和配置文件。为了避免手动输入，你可以 git clone Kubernetes 源到你本地。

Cassandra Docker 镜像

Pod 使用来自 Google 容器仓库 的 gcr.io/google-samples/cassandra:v12 镜像。这个 docker 镜像基于 debian:jessie 并包含 OpenJDK 8。该镜像包含一个从 Apache Debian 源中安装的标准 Cassandra。你可以通过使用环境变量改变插入到 cassandra.yaml 文件中的参数值。

ENV VARDEFAULT VALUE
CASSANDRA_CLUSTER_NAME‘Test Cluster’
CASSANDRA_NUM_TOKENS32
CASSANDRA_RPC_ADDRESS0.0.0.0

快速入门

application/cassandra/cassandra-service.yaml示例：使用 Stateful Sets 部署 Cassandra - 图1
  1. apiVersion: v1kind: Servicemetadata:  labels:    app: cassandra  name: cassandraspec:  clusterIP: None  ports:  - port: 9042  selector:    app: cassandra

如果你希望直接跳到我们使用的命令，以下是全部步骤：

  1. kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-service.yaml
application/cassandra/cassandra-statefulset.yaml示例：使用 Stateful Sets 部署 Cassandra - 图2
  1. apiVersion: apps/v1kind: StatefulSetmetadata:  name: cassandra  labels:    app: cassandraspec:  serviceName: cassandra  replicas: 3  selector:    matchLabels:      app: cassandra  template:    metadata:      labels:        app: cassandra    spec:      terminationGracePeriodSeconds: 1800      containers:      - name: cassandra        image: gcr.io/google-samples/cassandra:v13        imagePullPolicy: Always        ports:        - containerPort: 7000          name: intra-node        - containerPort: 7001          name: tls-intra-node        - containerPort: 7199          name: jmx        - containerPort: 9042          name: cql        resources:          limits:            cpu: "500m"            memory: 1Gi          requests:            cpu: "500m"            memory: 1Gi        securityContext:          capabilities:            add:              - IPC_LOCK        lifecycle:          preStop:            exec:              command:              - /bin/sh              - -c              - nodetool drain        env:          - name: MAX_HEAP_SIZE            value: 512M          - name: HEAP_NEWSIZE            value: 100M          - name: CASSANDRA_SEEDS            value: "cassandra-0.cassandra.default.svc.cluster.local"          - name: CASSANDRA_CLUSTER_NAME            value: "K8Demo"          - name: CASSANDRA_DC            value: "DC1-K8Demo"          - name: CASSANDRA_RACK            value: "Rack1-K8Demo"          - name: POD_IP            valueFrom:              fieldRef:                fieldPath: status.podIP        readinessProbe:          exec:            command:            - /bin/bash            - -c            - /ready-probe.sh          initialDelaySeconds: 15          timeoutSeconds: 5        # These volume mounts are persistent. They are like inline claims,        # but not exactly because the names need to match exactly one of        # the stateful pod volumes.        volumeMounts:        - name: cassandra-data          mountPath: /cassandra_data  # These are converted to volume claims by the controller  # and mounted at the paths mentioned above.  # do not use these in production until ssd GCEPersistentDisk or other ssd pd  volumeClaimTemplates:  - metadata:      name: cassandra-data    spec:      accessModes: [ "ReadWriteOnce" ]      storageClassName: fast      resources:        requests:          storage: 1Gi—-kind: StorageClassapiVersion: storage.k8s.io/v1metadata:  name: fastprovisioner: k8s.io/minikube-hostpathparameters:  type: pd-ssd
  1. # 创建 statefulset
  2. kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml
  4. # 验证 Cassandra 集群。替换一个 pod 的名称。
  5. kubectl exec -ti cassandra-0 -- nodetool status
  7. # 清理
  8. grace=$(kubectl get po cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \
  9.   && kubectl delete statefulset,po -l app=cassandra \
  10.   && echo "Sleeping $grace" \
  11.   && sleep $grace \
  12.   && kubectl delete pvc -l app=cassandra
  14. #
  15. # 资源控制器示例
  16. #
  18. # 创建一个副本控制器来复制 cassandra 节点
  19. kubectl create -f cassandra/cassandra-controller.yaml
  21. # 验证 Cassandra 集群。替换一个 pod 的名称。
  22. kubectl exec -ti cassandra-xxxxx -- nodetool status
  24. # 扩大 Cassandra 集群
  25. kubectl scale rc cassandra --replicas=4
  27. # 删除副本控制器
  28. kubectl delete rc cassandra
  30. #
  31. # 创建一个 DaemonSet，在每个 kubernetes 节点上放置一个 cassandra 节点
  32. #
  34. kubectl create -f cassandra/cassandra-daemonset.yaml --validate=false
  36. # 资源清理
  37. kubectl delete service -l app=cassandra
  38. kubectl delete daemonset cassandra

步骤 1：创建 Cassandra Headless Service

Kubernetes Service 描述一组执行同样任务的 Pod。在 Kubernetes 中，一个应用的原子调度单位是一个 Pod：一个或多个必须调度到相同主机上的容器。

这个 Service 用于在 Kubernetes 集群内部进行 Cassandra 客户端和 Cassandra Pod 之间的 DNS 查找。

以下为这个 service 的描述：

  1. apiVersion: v1
  2. kind: Service
  3. metadata:
  4.   labels:
  5.     app: cassandra
  6.   name: cassandra
  7. spec:
  8.   clusterIP: None
  9.   ports:
  10.     - port: 9042
  11.   selector:
  12.     app: cassandra

Download cassandra-service.yamland cassandra-statefulset.yaml

为 StatefulSet 创建 service

  1. kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-service.yaml

以下命令显示了 service 是否被成功创建。

  1. $ kubectl get svc cassandra

命令的响应应该像这样：

  1. NAME        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
  2. cassandra   None         <none>        9042/TCP   45s

如果返回错误则表示 service 创建失败。

步骤 2：使用 StatefulSet 创建 Cassandra Ring环

StatefulSets（以前叫做 PetSets）特性在 Kubernetes 1.5 中升级为一个 Beta 组件。在集群环境中部署类似于 Cassandra 的有状态分布式应用是一项具有挑战性的工作。我们实现了 StatefulSet，极大的简化了这个过程。本示例使用了 StatefulSet 的多个特性，但其本身超出了本文的范围。请参考 StatefulSet 文档。

以下是 StatefulSet 的清单文件，用于创建一个由三个 pod 组成的 Cassandra ring 环。

本示例使用了 GCE Storage Class，请根据你运行的云平台做适当的修改。

  1. apiVersion: "apps/v1beta1"
  2. kind: StatefulSet
  3. metadata:
  4.   name: cassandra
  5. spec:
  6.   serviceName: cassandra
  7.   replicas: 3
  8.   template:
  9.     metadata:
  10.       labels:
  11.         app: cassandra
  12.     spec:
  13.       containers:
  14.       - name: cassandra
  15.         image: gcr.io/google-samples/cassandra:v12
  16.         imagePullPolicy: Always
  17.         ports:
  18.         - containerPort: 7000
  19.           name: intra-node
  20.         - containerPort: 7001
  21.           name: tls-intra-node
  22.         - containerPort: 7199
  23.           name: jmx
  24.         - containerPort: 9042
  25.           name: cql
  26.         resources:
  27.           limits:
  28.             cpu: "500m"
  29.             memory: 1Gi
  30.           requests:
  31.            cpu: "500m"
  32.            memory: 1Gi
  33.         securityContext:
  34.           capabilities:
  35.             add:
  36.               - IPC_LOCK
  37.         lifecycle:
  38.           preStop:
  39.             exec:
  40.               command: ["/bin/sh", "-c", "PID=$(pidof java) && kill $PID && while ps -p $PID > /dev/null; do sleep 1; done"]
  41.         env:
  42.           - name: MAX_HEAP_SIZE
  43.             value: 512M
  44.           - name: HEAP_NEWSIZE
  45.             value: 100M
  46.           - name: CASSANDRA_SEEDS
  47.             value: "cassandra-0.cassandra.default.svc.cluster.local"
  48.           - name: CASSANDRA_CLUSTER_NAME
  49.             value: "K8Demo"
  50.           - name: CASSANDRA_DC
  51.             value: "DC1-K8Demo"
  52.           - name: CASSANDRA_RACK
  53.             value: "Rack1-K8Demo"
  54.           - name: CASSANDRA_AUTO_BOOTSTRAP
  55.             value: "false"
  56.           - name: POD_IP
  57.             valueFrom:
  58.               fieldRef:
  59.                 fieldPath: status.podIP
  60.         readinessProbe:
  61.           exec:
  62.             command:
  63.             - /bin/bash
  64.             - -c
  65.             - /ready-probe.sh
  66.           initialDelaySeconds: 15
  67.           timeoutSeconds: 5
  68.         # These volume mounts are persistent. They are like inline claims,
  69.         # but not exactly because the names need to match exactly one of
  70.         # the stateful pod volumes.
  71.         volumeMounts:
  72.         - name: cassandra-data
  73.           mountPath: /cassandra_data
  74.   # These are converted to volume claims by the controller
  75.   # and mounted at the paths mentioned above.
  76.   # do not use these in production until ssd GCEPersistentDisk or other ssd pd
  77.   volumeClaimTemplates:
  78.   - metadata:
  79.       name: cassandra-data
  80.       annotations:
  81.         volume.beta.kubernetes.io/storage-class: fast
  82.     spec:
  83.       accessModes: [ "ReadWriteOnce" ]
  84.       resources:
  85.         requests:
  86.           storage: 1Gi
  87. ---
  88. kind: StorageClass
  89. apiVersion: storage.k8s.io/v1beta1
  90. metadata:
  91.   name: fast
  92. provisioner: kubernetes.io/gce-pd
  93. parameters:
  94.   type: pd-ssd

创建 Cassandra StatefulSet 如下：

  1. kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml

步骤 3：验证和修改 Cassandra StatefulSet

这个 StatefulSet 的部署展示了 StatefulSets 提供的两个新特性：

  • Pod 的名称已知
  • Pod 以递增顺序部署首先，运行下面的 kubectl 命令，验证 StatefulSet 已经被成功部署。
  1. $ kubectl get statefulset cassandra

这个命令的响应应该像这样：

  1. NAME        DESIRED   CURRENT   AGE
  2. cassandra   3         3         13s

接下来观察 Cassandra pod 以一个接一个的形式部署。StatefulSet 资源按照数字序号的模式部署 pod：1, 2, 3 等。如果在 pod 部署前执行下面的命令，你就能够看到这种顺序的创建过程。

  1. $ kubectl get pods -l="app=cassandra"
  2. NAME          READY     STATUS              RESTARTS   AGE
  3. cassandra-0   1/1       Running             0          1m
  4. cassandra-1   0/1       ContainerCreating   0          8s

上面的示例显示了三个 Cassandra StatefulSet pod 中的两个已经部署。一旦所有的 pod 都部署成功，相同的命令会显示一个完整的 StatefulSet。

  1. $ kubectl get pods -l="app=cassandra"
  2. NAME          READY     STATUS    RESTARTS   AGE
  3. cassandra-0   1/1       Running   0          10m
  4. cassandra-1   1/1       Running   0          9m
  5. cassandra-2   1/1       Running   0          8m

运行 Cassandra 工具 nodetool 将显示 ring 环的状态。

  1. $ kubectl exec cassandra-0 -- nodetool status
  2. Datacenter: DC1-K8Demo
  3. ======================
  4. Status=Up/Down
  5. |/ State=Normal/Leaving/Joining/Moving
  6. --  Address   Load       Tokens       Owns (effective)  Host ID                               Rack
  7. UN  10.4.2.4  65.26 KiB  32           63.7%             a9d27f81-6783-461d-8583-87de2589133e  Rack1-K8Demo
  8. UN  10.4.0.4  102.04 KiB  32           66.7%             5559a58c-8b03-47ad-bc32-c621708dc2e4  Rack1-K8Demo
  9. UN  10.4.1.4  83.06 KiB  32           69.6%             9dce943c-581d-4c0e-9543-f519969cc805  Rack1-K8Demo

你也可以运行 cqlsh 来显示集群的 keyspaces。

  1. $ kubectl exec cassandra-0 -- cqlsh -e 'desc keyspaces'
  3. system_traces  system_schema  system_auth  system  system_distributed

你需要使用 kubectl edit 来增加或减小 Cassandra StatefulSet 的大小。你可以在文档 中找到更多关于 edit 命令的信息。

使用以下命令编辑 StatefulSet。

  1. $ kubectl edit statefulset cassandra

这会在你的命令行中创建一个编辑器。你需要修改的行是 replicas。这个例子没有包含终端窗口的所有内容，下面示例中的最后一行就是你希望改变的 replicas 行。

  1. # Please edit the object below. Lines beginning with a '#' will be ignored,
  2. # and an empty file will abort the edit. If an error occurs while saving this file will be
  3. # reopened with the relevant failures.
  4. #
  5. apiVersion: apps/v1beta1
  6. kind: StatefulSet
  7. metadata:
  8.   creationTimestamp: 2016-08-13T18:40:58Z
  9.   generation: 1
  10.   labels:
  11.     app: cassandra
  12.   name: cassandra
  13.   namespace: default
  14.   resourceVersion: "323"
  15.   uid: 7a219483-6185-11e6-a910-42010a8a0fc0
  16. spec:
  17.   replicas: 3

按下面的示例修改清单文件并保存。

  1. spec:
  2.   replicas: 4

这个 StatefulSet 现在将包含四个 pod。

  1. $ kubectl get statefulset cassandra

这个command的响应应该像这样：

  1. NAME        DESIRED   CURRENT   AGE
  2. cassandra   4         4         36m

对于 Kubernetes 1.5 发布版，beta StatefulSet 资源没有像 Deployment, ReplicaSet, Replication Controller 或者 Job 一样，包含 kubectl scale 功能，

步骤 4：删除 Cassandra StatefulSet

删除或者缩容 StatefulSet 时不会删除与之关联的 volumes。这样做是为了优先保证安全。你的数据比其它会被自动清除的 StatefulSet 关联资源更宝贵。删除 Persistent Volume Claims 可能会导致关联的 volumes 被删除，这种行为依赖 storage class 和 reclaim policy。永远不要期望能在 claim 删除后访问一个 volume。

使用如下命令删除 StatefulSet。

  1. $ grace=$(kubectl get po cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \
  2.   && kubectl delete statefulset -l app=cassandra \
  3.   && echo "Sleeping $grace" \
  4.   && sleep $grace \
  5.   && kubectl delete pvc -l app=cassandra

步骤 5：使用 Replication Controller 创建 Cassandra 节点 pod

Kubernetes Replication Controller 负责复制一个完全相同的 pod 集合。像 Service 一样，它具有一个 selector query，用来识别它的集合成员。和 Service 不一样的是，它还具有一个期望的副本数，并且会通过创建或删除 Pod 来保证 Pod 的数量满足它期望的状态。

和我们刚才定义的 Service 一起，Replication Controller 能够让我们轻松的构建一个复制的、可扩展的 Cassandra 集群。

让我们创建一个具有两个初始副本的 replication controller。

  1. apiVersion: v1
  2. kind: ReplicationController
  3. metadata:
  4.   name: cassandra
  5.   # The labels will be applied automatically
  6.   # from the labels in the pod template, if not set
  7.   # labels:
  8.     # app: cassandra
  9. spec:
  10.   replicas: 2
  11.   # The selector will be applied automatically
  12.   # from the labels in the pod template, if not set.
  13.   # selector:
  14.       # app: cassandra
  15.   template:
  16.     metadata:
  17.       labels:
  18.         app: cassandra
  19.     spec:
  20.       containers:
  21.         - command:
  22.             - /run.sh
  23.           resources:
  24.             limits:
  25.               cpu: 0.5
  26.           env:
  27.             - name: MAX_HEAP_SIZE
  28.               value: 512M
  29.             - name: HEAP_NEWSIZE
  30.               value: 100M
  31.             - name: CASSANDRA_SEED_PROVIDER
  32.               value: "io.k8s.cassandra.KubernetesSeedProvider"
  33.             - name: POD_NAMESPACE
  34.               valueFrom:
  35.                 fieldRef:
  36.                   fieldPath: metadata.namespace
  37.             - name: POD_IP
  38.               valueFrom:
  39.                 fieldRef:
  40.                   fieldPath: status.podIP
  41.           image: gcr.io/google-samples/cassandra:v12
  42.           name: cassandra
  43.           ports:
  44.             - containerPort: 7000
  45.               name: intra-node
  46.             - containerPort: 7001
  47.               name: tls-intra-node
  48.             - containerPort: 7199
  49.               name: jmx
  50.             - containerPort: 9042
  51.               name: cql
  52.           volumeMounts:
  53.             - mountPath: /cassandra_data
  54.               name: data
  55.       volumes:
  56.         - name: data
  57.           emptyDir: {}

下载示例

在这个描述中需要注意几件事情。

selector 属性包含了控制器的 selector query。它能够被显式指定，或者在没有设置时，像此处一样从 pod 模板中的 labels 中自动应用。

Pod 模板的标签 app:cassandra 匹配步骤1中的 Service selector。这就是 Service 如何选择 replication controller 创建的 pod 的原理。

replicas 属性指明了期望的副本数量，在本例中最开始为 2。我们很快将要扩容更多数量。

创建 Replication Controller：

  1. $ kubectl create -f cassandra/cassandra-controller.yaml

你可以列出新建的 controller：

  1. $ kubectl get rc -o wide
  2. NAME        DESIRED   CURRENT   AGE       CONTAINER(S)   IMAGE(S)                             SELECTOR
  3. cassandra   2         2         11s       cassandra      gcr.io/google-samples/cassandra:v12   app=cassandra

现在，如果你列出集群中的 pod，并且使用 app=cassandra 标签过滤，你应该能够看到两个 Cassandra pod。（wide 参数使你能够看到 pod 被调度到了哪个 Kubernetes 节点上）

  1. $ kubectl get pods -l="app=cassandra" -o wide
  2. NAME              READY     STATUS    RESTARTS   AGE       NODE
  3. cassandra-21qyy   1/1       Running   0          1m        kubernetes-minion-b286
  4. cassandra-q6sz7   1/1       Running   0          1m        kubernetes-minion-9ye5

因为这些 pod 拥有 app=cassandra 标签，它们被映射给了我们在步骤 1 中创建的 service。

你可以使用下面的 service endpoint 查询命令来检查 Pod 是否对 Service 可用。

  1. $ kubectl get endpoints cassandra -o yaml
  2. apiVersion: v1
  3. kind: Endpoints
  4. metadata:
  5.   creationTimestamp: 2015-06-21T22:34:12Z
  6.   labels:
  7.     app: cassandra
  8.   name: cassandra
  9.   namespace: default
  10.   resourceVersion: "944373"
  11.   uid: a3d6c25f-1865-11e5-a34e-42010af01bcc
  12. subsets:
  13. - addresses:
  14.   - ip: 10.244.3.15
  15.     targetRef:
  16.       kind: Pod
  17.       name: cassandra
  18.       namespace: default
  19.       resourceVersion: "944372"
  20.       uid: 9ef9895d-1865-11e5-a34e-42010af01bcc
  21.   ports:
  22.   - port: 9042
  23.     protocol: TCP

为了显示 SeedProvider 逻辑是按设想在运行，你可以使用 nodetool 命令来检查 Cassandra 集群的状态。为此，请使用 kubectl exec 命令，这样你就能在一个 Cassandra pod 上运行 nodetool。同样的，请替换 cassandra-xxxxx 为任意一个 pods的真实名字。

  1. $ kubectl exec -ti cassandra-xxxxx -- nodetool status
  2. Datacenter: datacenter1
  3. =======================
  4. Status=Up/Down
  5. |/ State=Normal/Leaving/Joining/Moving
  6. --  Address     Load       Tokens  Owns (effective)  Host ID                               Rack
  7. UN  10.244.0.5  74.09 KB   256     100.0%            86feda0f-f070-4a5b-bda1-2eeb0ad08b77  rack1
  8. UN  10.244.3.3  51.28 KB   256     100.0%            dafe3154-1d67-42e1-ac1d-78e7e80dce2b  rack1

步骤 6：Cassandra 集群扩容

现在，让我们把 Cassandra 集群扩展到 4 个 pod。我们通过告诉 Replication Controller 现在我们需要 4 个副本来完成。

  1. $ kubectl scale rc cassandra --replicas=4

你可以看到列出了新的 pod：

  1. $ kubectl get pods -l="app=cassandra" -o wide
  2. NAME              READY     STATUS    RESTARTS   AGE       NODE
  3. cassandra-21qyy   1/1       Running   0          6m        kubernetes-minion-b286
  4. cassandra-81m2l   1/1       Running   0          47s       kubernetes-minion-b286
  5. cassandra-8qoyp   1/1       Running   0          47s       kubernetes-minion-9ye5
  6. cassandra-q6sz7   1/1       Running   0          6m        kubernetes-minion-9ye5

一会儿你就能再次检查 Cassandra 集群的状态，你可以看到新的 pod 已经被自定义的 SeedProvider 检测到：

  1. $ kubectl exec -ti cassandra-xxxxx -- nodetool status
  2. Datacenter: datacenter1
  3. =======================
  4. Status=Up/Down
  5. |/ State=Normal/Leaving/Joining/Moving
  6. --  Address     Load       Tokens  Owns (effective)  Host ID                               Rack
  7. UN  10.244.0.6  51.67 KB   256     48.9%             d07b23a5-56a1-4b0b-952d-68ab95869163  rack1
  8. UN  10.244.1.5  84.71 KB   256     50.7%             e060df1f-faa2-470c-923d-ca049b0f3f38  rack1
  9. UN  10.244.1.6  84.71 KB   256     47.0%             83ca1580-4f3c-4ec5-9b38-75036b7a297f  rack1
  10. UN  10.244.0.5  68.2 KB    256     53.4%             72ca27e2-c72c-402a-9313-1e4b61c2f839  rack1

步骤 7：删除 Replication Controller

在你开始步骤 5 之前， 删除你在上面创建的 replication controller。

  1. $ kubectl delete rc cassandra

步骤 8：使用 DaemonSet 替换 Replication Controller

在 Kubernetes中，DaemonSet 能够将 pod 一对一的分布到 Kubernetes 节点上。和 ReplicationController 相同的是它也有一个用于识别它的集合成员的 selector query。但和 ReplicationController 不同的是，它拥有一个节点 selector，用于限制基于模板的 pod 可以调度的节点。并且 pod 的复制不是基于一个设置的数量，而是为每一个节点分配一个 pod。

示范用例：当部署到云平台时，预期情况是实例是短暂的并且随时可能终止。Cassandra 被搭建成为在各个节点间复制数据以便于实现数据冗余。这样的话，即使一个实例终止了，存储在它上面的数据却没有，并且集群会通过重新复制数据到其它运行节点来作为响应。

DaemonSet 设计为在 Kubernetes 集群中的每个节点上放置一个 pod。那样就会给我们带来数据冗余度。让我们创建一个 DaemonSet 来启动我们的存储集群：

  1. apiVersion: extensions/v1beta1
  2. kind: DaemonSet
  3. metadata:
  4.   labels:
  5.     name: cassandra
  6.   name: cassandra
  7. spec:
  8.   template:
  9.     metadata:
  10.       labels:
  11.         app: cassandra
  12.     spec:
  13.       # Filter to specific nodes:
  14.       # nodeSelector:
  15.       #  app: cassandra
  16.       containers:
  17.         - command:
  18.             - /run.sh
  19.           env:
  20.             - name: MAX_HEAP_SIZE
  21.               value: 512M
  22.             - name: HEAP_NEWSIZE
  23.               value: 100M
  24.             - name: CASSANDRA_SEED_PROVIDER
  25.               value: "io.k8s.cassandra.KubernetesSeedProvider"
  26.             - name: POD_NAMESPACE
  27.               valueFrom:
  28.                 fieldRef:
  29.                   fieldPath: metadata.namespace
  30.             - name: POD_IP
  31.               valueFrom:
  32.                 fieldRef:
  33.                   fieldPath: status.podIP
  34.           image: gcr.io/google-samples/cassandra:v12
  35.           name: cassandra
  36.           ports:
  37.             - containerPort: 7000
  38.               name: intra-node
  39.             - containerPort: 7001
  40.               name: tls-intra-node
  41.             - containerPort: 7199
  42.               name: jmx
  43.             - containerPort: 9042
  44.               name: cql
  45.               # If you need it, it will go away in C* 4.0.
  46.               #- containerPort: 9160
  47.               #  name: thrift
  48.           resources:
  49.             requests:
  50.               cpu: 0.5
  51.           volumeMounts:
  52.             - mountPath: /cassandra_data
  53.               name: data
  54.       volumes:
  55.         - name: data
  56.           emptyDir: {}

下载示例

这个 DaemonSet 绝大部分的定义和上面的 ReplicationController 完全相同；它只是简单的给 daemonset 一个创建新的 Cassandra pod 的方法，并且以集群中所有的 Cassandra 节点为目标。

不同之处在于 nodeSelector 属性，它允许 DaemonSet 以全部节点的一个子集为目标（你可以向其他资源一样标记节点），并且没有 replicas 属性，因为它使用1对1的 node-pod 关系。

创建这个 DaemonSet：

  1. $ kubectl create -f cassandra/cassandra-daemonset.yaml

你可能需要禁用配置文件检查，像这样：

  1. $ kubectl create -f cassandra/cassandra-daemonset.yaml --validate=false

你可以看到 DaemonSet 已经在运行：

  1. $ kubectl get daemonset
  2. NAME        DESIRED   CURRENT   NODE-SELECTOR
  3. cassandra   3         3         <none>

现在，如果你列出集群中的 pods，并且使用 app=cassandra 标签过滤，你应该能够看到你的网络中的每一个节点上都有一个（且只有一个）新的 cassandra pod。

  1. $ kubectl get pods -l="app=cassandra" -o wide
  2. NAME              READY     STATUS    RESTARTS   AGE       NODE
  3. cassandra-ico4r   1/1       Running   0          4s        kubernetes-minion-rpo1
  4. cassandra-kitfh   1/1       Running   0          1s        kubernetes-minion-9ye5
  5. cassandra-tzw89   1/1       Running   0          2s        kubernetes-minion-b286

为了证明这是按设想的在工作，你可以再次使用 nodetool 命令来检查集群的状态。为此，请使用 kubectl exec 命令在任何一个新建的 cassandra pod 上运行 nodetool。

  1. $ kubectl exec -ti cassandra-xxxxx -- nodetool status
  2. Datacenter: datacenter1
  3. =======================
  4. Status=Up/Down
  5. |/ State=Normal/Leaving/Joining/Moving
  6. --  Address     Load       Tokens  Owns (effective)  Host ID                               Rack
  7. UN  10.244.0.5  74.09 KB   256     100.0%            86feda0f-f070-4a5b-bda1-2eeb0ad08b77  rack1
  8. UN  10.244.4.2  32.45 KB   256     100.0%            0b1be71a-6ffb-4895-ac3e-b9791299c141  rack1
  9. UN  10.244.3.3  51.28 KB   256     100.0%            dafe3154-1d67-42e1-ac1d-78e7e80dce2b  rack1

注意：这个示例让你在创建 DaemonSet 前删除了 cassandra 的 Replication Controller。这是因为为了保持示例的简单，RC 和 DaemonSet 使用了相同的 app=cassandra 标签（如此它们的 pod 映射到了我们创建的 service，这样 SeedProvider 就能识别它们）。

如果我们没有预先删除 RC，这两个资源在需要运行多少 pod 上将会发生冲突。如果希望的话，我们可以使用额外的标签和 selectors 来支持同时运行它们。

步骤 9：资源清理

当你准备删除你的资源时，按以下执行：

  1. $ kubectl delete service -l app=cassandra
  2. $ kubectl delete daemonset cassandra

Seed Provider Source

我们使用了一个自定义的 SeedProvider 来在 Kubernetes 之上运行 Cassandra。仅当你通过 replication control 或者 daemonset 部署 Cassandra 时才需要使用自定义的 seed provider。在 Cassandra 中，SeedProvider 引导 Cassandra 使用 gossip 协议来查找其它 Cassandra 节点。Seed 地址是被视为连接端点的主机。Cassandra 实例使用 seed 列表来查找彼此并学习 ring 环拓扑。KubernetesSeedProvider 通过 Kubernetes API 发现 Cassandra seeds IP 地址，那些 Cassandra 实例在 Cassandra Service 中定义。

请查阅自定义 seed provider 的 README 文档，获取 KubernetesSeedProvider 进阶配置。对于本示例来说，你应该不需要自定义 Seed Provider 的配置。

查看本示例的 image 目录，了解如何构建容器的 docker 镜像及其内容。

你可能还注意到我们设置了一些 Cassandra 参数（MAX_HEAP_SIZE和HEAP_NEWSIZE），并且增加了关于 namespace 的信息。我们还告诉 Kubernetes 容器暴露了 CQL 和 Thrift API 端口。最后，我们告诉集群管理器我们需要 0.1 cpu（0.1 核）。

!Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/cassandra/README.md?pixel)