在 Kubernetes 上部署 InfluxDB 和 Grafana 以收集 Twitter 统计信息

通过 Python 脚本、InfluxDB 和 Grafana 在 Kubernetes 或 OKD 中运行来监控您的 Twitter 统计信息。

图片来源

Opensource.com

Kubernetes 是市场上容器编排领域的事实领导者，它是一个非常可配置且功能强大的编排工具。与许多强大的工具一样，它起初可能会让人感到有些困惑。本演练将涵盖创建多个 Pod、使用密钥凭据和配置文件配置它们，以及通过创建 InfluxDB 和 Grafana 部署以及 Kubernetes CronJob 来收集有关您的 Twitter 帐户（来自 Twitter 开发者 API）的统计信息，并将所有内容部署在 Kubernetes 或 OKD（以前称为 OpenShift Origin）上的基础知识。

要求

一个要监控的 Twitter 帐户
一个用于收集统计信息的 Twitter 开发者 API 帐户
一个 Kubernetes 或 OKD 集群（或 MiniKube 或 MiniShift）
已安装 kubectl 或 oc 命令行界面 (CLI) 工具

您将学到什么

本演练将向您介绍各种 Kubernetes 概念。您将学习 Kubernetes CronJob、ConfigMap、Secret、Deployment、Service 和 Ingress。

如果您选择进一步深入，包含的文件可以用作 Tweepy（一个“易于使用的 Python 模块，用于访问 Twitter API”）、InfluxDB 配置和自动 Grafana 仪表板提供程序的介绍。

架构

此应用包含一个 Python 脚本，该脚本按计划轮询 Twitter 开发者 API，以获取有关您的 Twitter 帐户的统计信息，并将它们作为时间序列数据存储在 InfluxDB 中。Grafana 在可自定义的仪表板上以用户友好的格式（计数和图表）显示数据。

所有这些组件都在 Kubernetes 或 OKD 管理的容器中运行。

先决条件

获取 Twitter 开发者 API 帐户

按照注册 Twitter 开发者帐户的说明进行操作，该帐户允许访问 Twitter API。记录您的 API_KEY、API_SECRET、ACCESS_TOKEN 和 ACCESS_SECRET 以供稍后使用。

克隆 TwitterGraph 仓库

TwitterGraph GitHub 仓库包含本项目所需的所有文件，以及一些使您想要重新开始时生活更轻松的文件。

设置 InfluxDB

InfluxDB 是一个专门为时间序列数据设计的开源数据存储。由于本项目将使用 Kubernetes CronJob 按计划轮询 Twitter，因此 InfluxDB 非常适合用于保存数据。

Docker 维护的 DockerHub 上的 InfluxDB 镜像非常适合本项目。它可以与 Kubernetes 和 OKD 开箱即用。

创建 Deployment

Kubernetes Deployment 描述了资源的期望状态。对于 InfluxDB，这是一个 Pod 中的单个容器，运行 InfluxDB 镜像的实例。

可以使用 kubectl create deployment 命令创建基本的 InfluxDB Deployment

kubectl create deployment influxdb --image=docker.io/influxdb:1.6.4

可以使用 kubectl get deployment 命令查看新创建的 Deployment

kubectl get deployments
NAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
influxdb   1         1         1            1           7m40s

可以使用 kubectl describe deployment 命令查看 Deployment 的具体详细信息

kubectl describe deployment influxdb
Name:                   influxdb
Namespace:              twittergraph
CreationTimestamp:      Mon, 14 Jan 2019 11:31:12 -0500
Labels:                 app=influxdb
Annotations:            deployment.kubernetes.io/revision=1
Selector:               app=influxdb
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=influxdb
  Containers:
   influxdb:
    Image:        docker.io/influxdb:1.6.4
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   influxdb-85f7b44c44 (1/1 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  8m    deployment-controller  Scaled up replica set influxdb-85f7b44c44 to 1

使用 Secret 配置 InfluxDB 凭据

目前，Kubernetes 正在运行一个 InfluxDB 容器，该容器使用来自 docker.io/influxdb:1.6.4 镜像的默认配置，但这对于数据库服务器来说不一定很有帮助。需要配置数据库以使用一组特定的凭据，并在重启之间存储数据库数据。

Kubernetes Secret 是一种存储敏感信息（例如密码）的方式，并将它们作为环境变量或挂载卷注入到正在运行的容器中。这非常适合存储数据库凭据和连接信息，既可以配置 InfluxDB，又可以告诉 Grafana 和 Python CronJob 如何连接到它。

您需要四条信息来完成这两项任务

INFLUXDB_DATABASE—要使用的数据库的名称
INFLUXDB_HOST—数据库服务器正在运行的主机名
INFLUXDB_USERNAME—用于登录的用户名
INFLUXDB_PASSWORD—用于登录的密码

使用 kubectl create secret 命令和一些基本凭据创建一个 Secret

kubectl create secret generic influxdb-creds \
  --from-literal=INFLUXDB_DATABASE=twittergraph \
  --from-literal=INFLUXDB_USERNAME=root \
  --from-literal=INFLUXDB_PASSWORD=root \
  --from-literal=INFLUXDB_HOST=influxdb

此命令创建一个名为 influxdb-creds 的“通用类型”Secret（与“tls-”或“docker-registry-type”Secret 相反），其中填充了一些默认凭据。Secret 使用键/值对来存储数据，这非常适合用作容器内的环境变量。

与上面的示例一样，可以使用 kubectl get secret 命令查看 Secret

kubectl get secret influxdb-creds
NAME             TYPE      DATA      AGE
influxdb-creds   Opaque    4         11s

可以使用 kubectl describe secret 命令查看 Secret 中包含的键（但不包括值）。在本例中，INFLUXDB*_ 键列在 influxdb-creds Secret 中

kubectl describe secret influxdb-creds
Name:         influxdb-creds
Namespace:    twittergraph
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
INFLUXDB_DATABASE:  12 bytes
INFLUXDB_HOST:      8 bytes
INFLUXDB_PASSWORD:  4 bytes
INFLUXDB_USERNAME:  4 bytes

现在 Secret 已经创建，它可以作为环境变量与运行数据库的 InfluxDB Pod 共享。

要与 InfluxDB Pod 共享 Secret，需要在之前创建的 Deployment 中将其引用为环境变量。可以使用 kubectl edit deployment 命令编辑现有的 Deployment，这将在您系统的默认编辑器集中打开 Deployment 对象。保存文件后，Kubernetes 会将更改应用到 Deployment。

要为每个 Secret 添加环境变量，需要修改 Deployment 中包含的 Pod 规范。具体来说，需要修改 .spec.template.spec.containers 数组以包含 envFrom 部分。

使用命令 kubectl edit deployment influxdb，在 Deployment 中找到该部分（此示例被截断）

spec:
  template:
    spec:
      containers:
      - image: docker.io/influxdb:1.6.4
        imagePullPolicy: IfNotPresent
        name: influxdb

此部分描述了一个非常基本的 InfluxDB 容器。可以使用 env 数组为每个要映射的键/值对将 Secret 添加到容器中。或者，可以使用 envFrom 将所有键/值对映射到容器中，使用键名作为变量。

对于 influxdb-creds Secret 中的值，容器规范将如下所示

spec:
  containers:
  - name: influxdb
    envFrom:
    - secretRef:
        name: influxdb-creds

编辑 Deployment 后，Kubernetes 将销毁正在运行的 Pod，并创建一个新的 Pod，其中包含映射的环境变量。请记住，Deployment 描述了期望状态，因此 Kubernetes 会用与该状态匹配的新 Pod 替换旧 Pod。

您可以使用 kubectl describe deployment influxdb 验证环境变量是否包含在您的 Deployment 中

Environment Variables from:
  influxdb-creds  Secret  Optional: false

为 InfluxDB 配置持久存储

如果每次重启服务时都销毁其所有数据，则数据库就不是很有用。在当前的 InfluxDB Deployment 中，所有数据都存储在容器中，并在 Kubernetes 销毁并重新创建 Pod 时丢失。需要 PersistentVolume 来永久存储数据。

要在 Kubernetes 集群中获得持久存储，需要创建一个 PersistentVolumeClaim (PVC)，该 PVC 描述了所需卷的类型和详细信息，Kubernetes 将找到先前创建的符合请求的卷（或者，如果存在动态卷配置器，则创建一个卷）。

遗憾的是，kubectl CLI 工具无法直接创建 PVC，但 PVC 可以指定为 YAML 文件，并使用 kubectl create -f <filename> 创建。

创建一个名为 pvc.yaml 的文件，其中包含通用的 2G 声明

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: influxdb
    project: twittergraph
  name: influxdb
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

然后，创建 PVC

kubectl create -f pvc.yaml

您可以使用 kubectl get pvc 验证 PVC 是否已创建并绑定到 PersistentVolume

kubectl get pvc
NAME       STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
influxdb   Bound     pvc-27c7b0a7-1828-11e9-831a-0800277ca5a7   2Gi        RWO            standard       173m

从上面的输出中，您可以看到 PVC influxdb 已与名为 pvc-27c7b0a7-1828-11e9-831a-0800277ca5a7 的 PV（或卷）匹配（您的名称会有所不同）并绑定（STATUS：Bound）。

如果您的 PVC 没有卷，或者状态不是 Bound，您可能需要与集群管理员联系。（此过程应适用于 MiniKube、MiniShift 或任何具有动态配置卷的集群。）

一旦 PersistentVolume 被分配给 PVC，就可以将该卷挂载到容器中以提供持久存储。同样，这需要编辑 Deployment，首先添加卷对象，其次在容器规范中将该卷引用为 volumeMount。

使用 kubectl edit deployment influxdb 编辑 Deployment，并在容器部分下方添加 .spec.template.spec.volumes 部分（为简洁起见，示例被截断）

spec:
  template:
    spec:
      volumes:
      - name: var-lib-influxdb
        persistentVolumeClaim:
          claimName: influxdb

在本示例中，名为 var-lib-influxdb 的卷已添加到 Deployment 中，该卷引用了之前创建的 PVC influxdb。

现在，将 volumeMount 添加到容器规范。卷挂载引用了之前添加的卷（name: var-lib-influxdb），并将该卷挂载到 InfluxDB 数据目录 /var/lib/influxdb

spec:
  template:
    spec:
      containers:
        volumeMounts:
        - mountPath: /var/lib/influxdb
          name: var-lib-influxdb

InfluxDB Deployment

完成上述操作后，您应该拥有一个 InfluxDB 的 Deployment，它看起来像这样

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "3"
  creationTimestamp: null
  generation: 1
  labels:
    app: influxdb
    project: twittergraph
  name: influxdb
  selfLink: /apis/extensions/v1beta1/namespaces/twittergraph/deployments/influxdb
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: influxdb
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: influxdb
    spec:
      containers:
      - envFrom:
        - secretRef:
            name: influxdb-creds
        image: docker.io/influxdb:1.6.4
        imagePullPolicy: IfNotPresent
        name: influxdb
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /var/lib/influxdb
          name: var-lib-influxdb
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      volumes:
      - name: var-lib-influxdb
        persistentVolumeClaim:
          claimName: influxdb
status: {}

使用 Service 公开 InfluxDB（仅限集群内部）

默认情况下，本项目中的 Pod 无法相互通信。需要 Kubernetes Service 将 Pod “公开”给集群或公共网络。对于 InfluxDB，Pod 需要能够接受来自 Grafana 和 CronJob Pod（稍后创建）的 TCP 端口 8086 上的流量。为此，使用 Cluster IP 公开（即，为 Pod 创建服务）。Cluster IP 仅对集群中的其他 Pod 可用。使用 kubectl expose 命令执行此操作

kubectl expose deployment influxdb --port=8086 --target-port=8086 --protocol=TCP --type=ClusterIP

可以使用 kubectl describe service 命令验证新创建的服务

kubectl describe service influxdb
Name:              influxdb
Namespace:         twittergraph
Labels:            app=influxdb
                   project=twittergraph
Annotations:       <none>
Selector:          app=influxdb
Type:              ClusterIP
IP:                10.108.196.112
Port:              <unset>  8086/TCP
TargetPort:        8086/TCP
Endpoints:         172.17.0.5:8086
Session Affinity:  None
Events:            <none>

某些详细信息（特别是 IP 地址）将与示例有所不同。“IP”是集群内部的 IP 地址，已通过该地址分配给服务，其他 Pod 可以通过该地址与 InfluxDB 通信。“Endpoints”是容器的 IP 和端口，用于侦听连接。该服务会将流量从内部集群 IP 路由到容器本身。

现在 InfluxDB 已设置完成，接下来设置 Grafana。

设置 Grafana

Grafana 是一个用于可视化时间序列数据的开源项目（可以理解为：漂亮、漂亮的图表）。

与 InfluxDB 一样，DockerHub 上的官方 Grafana 镜像也适用于本项目，包括 Kubernetes 和 OKD。

创建 Deployment

与之前一样，基于官方 Grafana 镜像创建一个 Deployment

kubectl create deployment grafana --image=docker.io/grafana/grafana:5.3.2

现在应该有一个与 influxdb Deployment 并排的 grafana Deployment

kubectl get deployments
NAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
grafana    1         1         1            1           7s
influxdb   1         1         1            1           5h12m

使用 Secret 和 ConfigMap 设置 Grafana 凭据和配置文件

在您已经学到的知识的基础上，配置 Grafana 应该既相似又更简单。Grafana 不需要持久存储，因为它从 InfluxDB 数据库中读取数据。但是，它确实需要两个配置文件来设置仪表板提供程序，以便从文件中动态加载仪表板、仪表板文件本身、将仪表板文件连接到 InfluxDB 作为数据源的文件，以及最后用于存储默认登录凭据的 Secret。

凭据 Secret 的工作方式与已创建的 influxdb-creds Secret 相同。默认情况下，Grafana 镜像会查找名为 GF_SECURITY_ADMIN_USER 和 GF_SECURITY_ADMIN_PASSWORD 的环境变量，以在启动时设置管理员用户名和密码。这些可以是您喜欢的任何内容，但请记住它们，以便您可以在配置 Grafana 后使用它们登录。

使用 kubectl create secret 命令为 Grafana 凭据创建一个名为 grafana-creds 的 Secret

kubectl create secret generic grafana-creds \
  --from-literal=GF_SECURITY_ADMIN_USER=admin \
  --from-literal=GF_SECURITY_ADMIN_PASSWORD=graphsRcool

使用 envFrom 将此 Secret 作为环境变量共享，这次在 Grafana Deployment 中。使用 kubectl edit deployment grafana 编辑 Deployment，并将环境变量添加到容器规范

spec:
  containers:
  - name: grafana
    envFrom:
    - secretRef:
        name: grafana-creds

使用 kubectl describe deployment grafana 验证环境变量是否已添加到 Deployment 中

Environment Variables from:
  grafana-creds  Secret  Optional: false

这就是开始使用 Grafana 的所有必需操作。如果需要，其余配置可以在 Web 界面中完成，但只需几个配置文件，Grafana 就可以在启动时完全配置。

Kubernetes ConfigMap 类似于 Secret，并且可以被 Pod 以相同的方式使用，但它们不会在 Kubernetes 中混淆存储信息。ConfigMap 对于将配置文件或变量添加到 Pod 中的容器非常有用。

本项目中的 Grafana 实例有三个需要写入正在运行的容器中的配置文件

influxdb-datasource.yml—告诉 Grafana 如何与 InfluxDB 数据库通信
grafana-dashboard-provider.yml—告诉 Grafana 在哪里查找描述仪表板的 JSON 文件
twittergraph-dashboard.json—描述用于显示收集的 Twitter 数据的仪表板

Kubernetes 可以轻松添加这些文件：它们可以一次全部添加到同一个 ConfigMap 中，并且尽管它们位于同一个 ConfigMap 中，但可以将它们挂载到文件系统上的不同位置。

如果您尚未这样做，请克隆 TwitterGraph GitHub 仓库。这些文件确实是本项目特有的，因此最简单的使用方法是直接从仓库中使用它们（尽管当然可以手动编写它们）。

从包含仓库内容的目录中，使用 kubectl create configmap 命令创建一个名为 grafana-config 的 ConfigMap

kubectl create configmap grafana-config \
  --from-file=influxdb-datasource.yml=influxdb-datasource.yml \
  --from-file=grafana-dashboard-provider.yml=grafana-dashboard-provider.yml \
  --from-file=twittergraph-dashboard.json=twittergraph-dashboard.json

kubectl create configmap 命令创建一个名为 grafana-config 的 ConfigMap，并将内容存储为指定键的值。--from-file 参数遵循 --from-file=<keyname>=<pathToFile> 格式，因此在本例中，文件名用作键，以便将来清晰。

与 Secret 类似，可以使用 kubectl describe configmap 查看 ConfigMap 的详细信息。与 Secret 不同，ConfigMap 的内容在输出中可见。使用 kubectl describe configmap grafana-config 查看存储为 ConfigMap 中键的三个文件（结果被截断，因为它们非常长）

kubectl describe configmap grafana-config
kubectl describe cm grafana-config
Name:         grafana-config
Namespace:    twittergraph
Labels:       <none>
Annotations:  <none>

Data
====
grafana-dashboard-provider.yml:
----
apiVersion: 1

providers:
- name: 'default'
  orgId: 1
  folder: ''
  type: file
<snip>

每个文件名都应存储为键，其内容应存储为值（例如上面的 grafana-dashboard-provider.yml）。

虽然 ConfigMap 可以作为环境变量共享（如上面的凭据 Secret），但此 ConfigMap 的内容需要作为文件挂载到容器中。为此，可以从 grafana Deployment 中的 ConfigMap 创建卷。与持久卷类似，使用 kubectl edit deployment grafana 添加卷 .spec.template.spec.volumes

spec:
  template:
    spec:
      volumes:
      - configMap:
          name: grafana-config
        name: grafana-config

然后编辑容器规范，以将存储在 ConfigMap 中的每个键作为文件挂载到 Grafana 容器中各自的位置。在 .spec.template.spec.containers 下，为卷添加 volumeMounts 部分

spec:
  template:
    spec:
      containers:
      - name: grafana
        volumeMounts:
        - mountPath: /etc/grafana/provisioning/datasources/influxdb-datasource.yml
          name: grafana-config
          readOnly: true
          subPath: influxdb-datasource.yml
        - mountPath: /etc/grafana/provisioning/dashboards/grafana-dashboard-provider.yml
          name: grafana-config
          readOnly: true
          subPath: grafana-dashboard-provider.yml
        - mountPath: /var/lib/grafana/dashboards/twittergraph-dashboard.json
          name: grafana-config
          readOnly: true
          subPath: twittergraph-dashboard.json

name 部分引用 ConfigMap volume 的名称，添加 subPath 项允许 Kubernetes 挂载每个文件，而不会覆盖该目录的其余内容。如果没有它，例如 /etc/grafana/provisioning/datasources/influxdb-datasource.yml 将是 /etc/grafana/provisioning/datasources 中唯一的文件。

可以使用 kubectl exec 命令通过在正在运行的容器中查看它们来验证每个文件。首先，找到 Grafana Pod 的当前名称。Pod 将具有类似于 grafana-586775fcc4-s7r2z 的随机名称，并且在运行命令 kubectl get pods 时应可见

kubectl get pods
NAME                        READY     STATUS    RESTARTS   AGE
grafana-586775fcc4-s7r2z    1/1       Running   0          93s
influxdb-595487b7f9-zgtvx   1/1       Running   0          18h

替换您的 Grafana Pod 的名称，您可以验证 influxdb-datasource.yml 文件的内容，例如（为简洁起见，已截断）

kubectl exec -it grafana-586775fcc4-s7r2z cat /etc/grafana/provisioning/datasources/influxdb-datasource.yml
# config file version
apiVersion: 1

# list of datasources to insert/update depending
# what's available in the database
datasources:
  # <string, required> name of the datasource. Required
- name: influxdb

公开 Grafana 服务

现在已配置完成，公开 Grafana 服务，以便可以在浏览器中查看它。由于 Grafana 应该从集群外部可见，因此将使用 LoadBalancer 服务类型，而不是仅限内部使用的 ClusterIP 类型。

对于支持 LoadBalancer 服务的生产集群或云环境，在创建服务时会动态配置外部 IP。对于 MiniKube 或 MiniShift，LoadBalancer 服务通过 minikube service 命令提供，该命令会将您的默认浏览器打开到一个 URL 和端口，您可以在主机 VM 上访问该服务。

Grafana Deployment 正在端口 3000 上侦听 HTTP 流量。使用 LoadBalancer 类型服务公开它，使用 kubectl expose 命令

kubectl expose deployment grafana --type=LoadBalancer --port=80 --target-port=3000 --protocol=TCP
service/grafana exposed

公开服务后，您可以使用 kubectl get service grafana 验证配置

kubectl get service grafana
NAME      TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
grafana   LoadBalancer   10.101.113.249   <pending>     80:31235/TCP   9m35s

如上所述，MiniKube 和 MiniShift Deployment 不会自动分配 EXTERNAL-IP，并且将列为 <pending>。运行 minikube service grafana （或 minikube service grafana --namespace <namespace> 如果您在 Default 以外的命名空间中创建了 Deployment）将打开您的默认浏览器到 IP 和端口组合，Grafana 在该组合中在您的主机 VM 上公开。

此时，Grafana 已配置为与 InfluxDB 通信，并已自动配置仪表板以显示 Twitter 统计信息。现在是时候获取一些实际的统计信息并将它们放入数据库中了。

创建 CronJob

Kubernetes CronJob，就像它的同名 cron 一样，是一种按特定计划运行作业的方式。在 Kubernetes 的情况下，作业是在容器中运行的任务：Kubernetes Job 由 Kubernetes 调度和跟踪，以确保其完成。

对于本项目，CronJob 是一个运行Python 脚本以收集 Twitter 统计信息的单个容器。

为 Twitter API 凭据创建一个 Secret

CronJob 使用您的 Twitter API 凭据连接到 API，并从容器内的环境变量中提取统计信息。创建一个 Secret 来存储 Twitter API 凭据和要从中收集统计信息的帐户名称（在下面替换您自己的凭据和帐户名称）

kubectl create secret generic twitter-creds \
    --from-literal=TWITTER_ACCESS_SECRET=<your twitter access secret> \
    --from-literal=TWITTER_ACCESS_TOKEN=<your twitter access token> \
    --from-literal=TWITTER_API_KEY=<your twitter api key > \
    --from-literal=TWITTER_API_SECRET=<your twitter api secret> \
    --from-literal=TWITTER_USER=<your twitter username>

创建 CronJob

最后，是时候创建 CronJob 来收集统计信息了。遗憾的是，kubectl 没有直接创建 CronJob 的方法，因此再次必须在 YAML 文件中描述对象，并使用 kubectl create -f <filename> 加载。

创建一个名为 cronjob.yml 的文件，描述要运行的作业

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  labels:
    app: twittergraph
  name: twittergraph
spec:
  concurrencyPolicy: Replace
  failedJobsHistoryLimit: 3
  jobTemplate:
    metadata:
    spec:
      template:
        metadata:
        spec:
          containers:
          - envFrom:
            - secretRef:
                name: twitter-creds
            - secretRef:
                name: influxdb-creds
            image: docker.io/clcollins/twittergraph:1.0
            imagePullPolicy: Always
            name: twittergraph
          restartPolicy: Never
  schedule: '*/3 * * * *'
  successfulJobsHistoryLimit: 3

查看此文件，Kubernetes CronJob 的关键部分显而易见。CronJob 规范包含一个 jobTemplate，用于描述要运行的 Kubernetes Job。在本例中，该作业由一个容器组成，该容器使用在 Deployment 中使用的 envFrom 将 Twitter 和 InfluxDB 凭据的 Secret 作为环境变量共享。

此作业使用来自 Docker Hub 的自定义镜像 clcollins/twittergraph:1.0。该镜像只是 Python 3.6，并且包含 app.py Python 脚本，用于 TwitterGraph。（如果您宁愿自己构建镜像，可以按照 GitHub 仓库中 BUILDING.md 中的说明使用 Source-To-Image 构建镜像。）

包装 Job 模板规范的是 CronJob 规范选项。最重要的部分，除了作业本身之外，可以说是 schedule，此处设置为每 3 分钟永远运行一次。另一个重要的部分是 concurrencyPolicy，它设置为 replace，因此如果上一个作业仍在运行时，则销毁运行旧作业的 Pod，并用新 Pod 替换。

使用 kubectl create -f cronjob.yml 命令创建 CronJob

kubectl create -f cronjob.yaml
cronjob.batch/twittergraph created

然后可以使用 kubectl describe cronjob twittergraph 验证 CronJob（为简洁起见，示例被截断）

kubectl describe cronjob twitterGraph
Name:                       twittergraph
Namespace:                  twittergraph
Labels:                     app=twittergraph
Annotations:                <none>
Schedule:                   */3 * * * *
Concurrency Policy:         Replace
Suspend:                    False
Starting Deadline Seconds:  <unset>

注意： 将计划设置为 */3 * * * * 时，Kubernetes 不会立即启动新作业。它将等待三分钟，等待第一个周期过去。如果您想立即查看结果，可以使用 kubectl edit cronjob twittergraph 编辑 CronJob，并将计划（临时）更改为 * * * * * 以每分钟运行一次。只是完成后不要忘记改回。

成功！

应该就是这样了。如果您已正确遵循所有步骤，您将拥有一个 InfluxDB 数据库、一个 CronJob，用于从您的 Twitter 帐户收集统计信息，以及一个 Grafana Deployment 来查看数据。对于 Kubernetes 或 OpenShift 的生产集群或云部署，请访问 LoadBalancer IP 以使用您之前使用 GF_SECURITY_ADMIN_USER 和 GF_SECURITY_ADMIN_PASSWORD 设置的凭据登录 Grafana。登录后，从屏幕左上角的“Home”下拉列表中选择 TwitterGraph 仪表板。您应该看到类似于下图的内容，其中包含您的关注者、您正在关注的人、状态更新、点赞和列表的当前计数。起初可能有点无聊，但如果您让它运行，随着时间的推移和更多的数据收集，图表将开始看起来更有趣并提供更有用的数据！

A new TwitterGraph deployment with just a little data

后续步骤

TwitterGraph 脚本收集的数据相对简单。收集的统计信息在 data_points 字典中的 app.py 脚本中描述，但有大量可用数据。添加一个新的 CronJob，每天运行以收集当天的活动（帖子数、关注数等）将是数据的自然扩展。可能更有趣的是关联每日数据收集，例如，根据当天的帖子数等，获得了多少或失去了多少关注者。

接下来阅读什么