统计twitter帖子_在Kubernetes上部署InfluxDB和Grafana以收集Twitter统计信息-白红宇

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

阅读量：2523 次

发布时间：2019-05-11

本文共 19667 字，大约阅读时间需要 65 分钟。

统计twitter帖子

Kubernetes是市场上容器编排的事实上的领导者，它是一种令人难以置信的可配置且功能强大的编排工具。与许多强大的工具一样，一开始它可能会让人感到困惑。本演练将介绍创建多个Pod，使用秘密凭证和配置文件对其进行配置以及通过创建InfluxDB和Grafana部署以及Kubernetes cron作业向Twitter公开服务的基础知识，以从Twitter收集有关Twitter帐户的统计信息。开发人员API，全部部署在Kubernetes或OKD（以前称为OpenShift Origin）上。

要求

一个要监视的Twitter帐户

Twitter开发人员API帐户，用于收集统计信息

Kubernetes或OKD集群（或MiniKube或MiniShift）

已安装kubectl或oc命令行界面（CLI）工具

您将学到什么

本演练将向您介绍各种Kubernetes概念。您将了解Kubernetes cron作业，ConfigMap，秘密，部署，服务和Ingress。

如果您选择进一步研究，则包含的文件可以用作的简介，是“用于访问Twitter API的易于使用的Python模块”，InfluxDB配置和自动Grafana 。

建筑

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

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

先决条件

获取一个Twitter开发人员API帐户

按照说明，该允许访问Twitter API。记录您的API_KEY ， API_SECRET ， ACCESS_TOKEN和ACCESS_SECRET以便以后使用。

克隆TwitterGraph回购

GitHub存储库包含该项目所需的所有文件，以及一些使您的生活更轻松的文件。

设置InfluxDB

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

DockerHub上由在该项目中可以正常工作。它可以与Kubernetes和OKD一起使用。

创建部署

描述了所需的资源状态。对于InfluxDB，这是运行InfluxDB映像实例的Pod中的单个容器。

可以使用kubectl create deployment命令创建准系统InfluxDB部署：

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

可以使用kubectl get deployment命令查看新创建的部署：

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

可以使用kubectl describe 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:         
    
          
         Host Port:    
     
           
         Environment:  
      
            
         Mounts:       
       
             
       Volumes:        
        
              
     Conditions:     
       Type           Status  Reason     
       ----           ------  ------     
       Available      True    MinimumReplicasAvailable     
       Progressing    True    NewReplicaSetAvailable     
     OldReplicaSets:  
         
           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

使用密码配置InfluxDB凭据

当前，Kubernetes正在使用docker.io/influxdb:1.6.4映像中的默认配置运行InfluxDB容器，但这不一定对数据库服务器很有帮助。需要将数据库配置为使用一组特定的凭据，并在两次重新启动之间存储数据库数据。

是一种存储敏感信息（例如密码）并将其作为环境变量或装入的卷注入运行中的容器的方法。这对于存储数据库凭据和连接信息非常理想，既可以配置InfluxDB，也可以告诉Grafana和Python cron作业如何连接到数据库。

您需要四点信息才能完成这两项任务：

INFLUXDB_DATABASE —要使用的数据库的名称

INFLUXDB_HOST-运行数据库服务器的主机名

INFLUXDB_USERNAME —用于登录的用户名

INFLUXDB_PASSWORD —用于登录的密码

使用kubectl create 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的“通用类型”密钥（与“ tls-”或“ docker-注册表类型”密钥相对），并填充一些默认凭据。机密使用键/值对存储数据，这非常适合用作容器内的环境变量。

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

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

可以使用kubectl describe secret命令查看密钥中包含的密钥（但不能看到值）。在这种情况下， influxdb-creds密钥中列出了INFLUXDB * _键：

kubectl describe secret influxdb-creds     
     Name:         influxdb-creds     
     Namespace:    twittergraph     
     Labels:       
    
          
     Annotations:  
     
           
          
     Type:  Opaque     
          
     Data     
     ====     
     INFLUXDB_DATABASE:  12 bytes     
     INFLUXDB_HOST:      8 bytes     
     INFLUXDB_PASSWORD:  4 bytes     
     INFLUXDB_USERNAME:  4 bytes

现在已经创建了秘密，可以将其作为与运行数据库的InfluxDB pod共享。

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

要为每个机密添加环境变量，需要修改部署中包含的pod规范。具体来说，需要修改.spec.template.spec.containers数组以包含envFrom节。

使用命令kubectl编辑部署influxdb ，在部署中找到该部分（此示例被截断）：

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

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

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

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

编辑部署后，Kubernetes将销毁正在运行的Pod，并使用映射的环境变量创建一个新Pod。请记住，部署描述了所需的状态 ，因此Kubernetes用与该状态匹配的新Pod替换了旧Pod。

您可以使用kubectl describe deploy influxdb验证部署中是否包含环境变量：

Environment Variables from:     
       influxdb-creds  Secret  Optional: false

为InfluxDB配置永久存储

如果每次重新启动服务时数据库的所有数据都被破坏，则数据库不是很有用。在当前的InfluxDB部署中，所有数据都存储在容器中，并在Kubernetes销毁并重新创建Pod时丢失。需要一个来永久存储数据。

为了在Kubernetes集群中获得持久性存储，将创建一个（PVC），其中描述了所需卷的类型和详细信息，并且Kubernetes将找到一个符合请求的先前创建的卷（或者使用动态卷配置程序创建一个该卷）。有一个）。

不幸的是， kubectl CLI工具无法直接创建PVC，但是可以将PVC指定为YAML文件，并使用kubectl create -f <filename>进行创建 ：

创建一个具有2G通用声明的名为pvc.yaml的文件：

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（或卷）匹配（您的名称会有所不同）并绑定（状态：绑定）。

如果您的PVC没有卷，或者状态不是“绑定”，则可能需要与集群管理员联系。（此过程应与MiniKube，MiniShift或具有动态预配置卷的任何群集一起正常工作。）

将PersistentVolume分配给PVC后，可以将该卷安装到容器中以提供持久存储。再一次，这需要编辑部署，首先添加一个卷对象，其次在容器规范内将该卷引用为volumeMount 。

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

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

在此示例中，名为var-lib-influxdb的卷被添加到部署中，该卷引用了先前创建的PVC influxdb 。

现在，将volumeMount添加到容器规范中。卷挂载引用先前添加的卷（ 名称：var-lib-influxdb ），并将该卷挂载到InfluxDB数据目录/ var / lib / influxdb ：

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

InfluxDB部署

完成上述操作之后，您应该具有一个类似以下内容的InfluxDB部署：

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: {}

使用服务公开InfluxDB（仅到群集）

默认情况下，此项目中的Pod无法互相交谈。需要将Pod“暴露”给集群或公众。在InfluxDB的情况下，该容器需要能够从Grafana和cron作业容器（稍后创建）在TCP端口8086上接受流量。为此，请使用群集IP公开（即为其创建服务）。群集IP仅对群集中的其他Pod可用。使用kubectl暴露命令做到这一点：

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:       
    
          
     Selector:          app=influxdb     
     Type:              ClusterIP     
     IP:                10.108.196.112     
     Port:              
     
        8086/TCP     
     TargetPort:        8086/TCP     
     Endpoints:         172.17.0.5:8086     
     Session Affinity:  None     
     Events:

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

现在已经设置了InfluxDB，继续进行Grafana。

设置Grafana

是一个开放源代码项目，用于可视化时间序列数据（认为：漂亮的图形）。

与InfluxDB一样，上的与Kubernetes和OKD一起为该项目直接使用。

创建部署

和以前一样，根据官方Grafana映像创建部署：

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

现在应该在influxdb部署旁边有一个grafana部署：

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

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

根据您已经学到的知识，配置Grafana应该既相似又容易。 Grafana不需要持久性存储，因为它正在从InfluxDB数据库中读取其数据。但是，它确实需要两个配置文件来设置以从文件动态加载仪表板，仪表板文件本身，将仪表板文件作为数据源连接到InfluxDB的文件，以及最后一个存储默认登录凭证的秘密。

凭证机密与已创建的influxdb-creds机密相同。默认情况下，Grafana映像会查找名为GF_SECURITY_ADMIN_USER和GF_SECURITY_ADMIN_PASSWORD的环境变量，以在启动时设置管理员用户名和密码。这些可以随心所欲，但是请记住它们，以便在配置Grafana后使用它们登录Grafana。

使用kubectl create secret命令为Grafana凭证创建一个名为grafana-creds的秘密：

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

这次在Grafana部署中使用envFrom将此秘密作为环境变量共享。使用kubectl编辑部署， 编辑部署grafana并将环境变量添加到容器规范中：

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

使用kubectl describe deployment grafana验证是否已将环境变量添加到部署中 ：

Environment Variables from:     
       grafana-creds  Secret  Optional: false

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

与机密相似，吊舱可以以相同的方式使用它，但是它们不存储在Kubernetes中混淆的信息。配置映射对于将配置文件或变量添加到Pod的容器中很有用。

该项目中的Grafana实例具有三个配置文件，需要将它们写入正在运行的容器中：

influxdb-datasource.yml —告诉Grafana如何与InfluxDB数据库对话

grafana-dashboard-provider.yml —告诉Grafana在哪里寻找描述仪表板的JSON文件

twittergraph-dashboard.json-描述用于显示收集的Twitter数据的仪表板

Kubernetes使添加这些文件变得容易：它们都可以一次添加到同一配置映射中，并且尽管它们位于同一配置映射中，也可以挂载到文件系统上的不同位置。

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

在包含仓库内容的目录中，使用kubectl create configmap命令创建一个名为grafana-config的配置映射：

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的配置图，并将内容存储为指定键的值。 --from-file参数采用--from-file = <密钥名> = <pathToFile>的形式 ，因此，在这种情况下，文件名将用作以后的说明的密钥。

就像秘密一样，可以使用kubectl describe configmap查看配置映射的详细信息。与秘密不同，配置映射的内容在输出中可见。使用kubectl describe configmap grafana-config查看在配置图中存储为键的三个文件（结果被截断，因为它们太稀疏了）：

kubectl describe configmap grafana-config     
     kubectl describe cm grafana-config     
     Name:         grafana-config     
     Namespace:    twittergraph     
     Labels:       
    
          
     Annotations:  
     
           
          
     Data     
     ====     
     grafana-dashboard-provider.yml:     
     ----     
     apiVersion: 1     
          
     providers:     
     - name: 'default'     
       orgId: 1     
       folder: ''     
       type: file

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

虽然可以将配置映射作为环境变量共享（如上面的凭据机密），但是此配置映射的内容需要作为文件安装到容器中。为此，可以从grafana部署中的配置映射创建卷。与持久卷类似，使用kubectl编辑部署grafana添加卷.spec.template.spec.volumes ：

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

然后编辑容器规范，以将存储在配置映射中的每个键作为文件安装在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

名称部分引用配置映射卷的名称，添加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窗格的名称，您可以验证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:     
       # 
    
      name of the datasource. Required     
     - name: influxdb

公开Grafana服务

现在已经配置好了，公开Grafana服务，以便可以在浏览器中查看它。因为应该从群集外部看到Grafana，所以将使用LoadBalancer服务类型，而不是仅内部使用的ClusterIP类型。

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

Grafana部署正在端口3000上侦听HTTP流量。使用kubectl暴露命令使用LoadBalancer类型的服务公开它：

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   
    
          80:31235/TCP   9m35s

如上所述，MiniKube和MiniShift部署不会自动分配EXTERNAL-IP ，而是列为<pending> 。运行minikube服务grafana （如果您在Default以外的名称空间中创建了部署，则运行minikube服务grafana --namespace <namespace> ）将打开默认浏览器，打开IP地址和端口组合，在主机VM上显示Grafana。

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

创建cron作业

像其同名的，是一种按特定时间表运行作业的方法。对于Kubernetes，该作业是在容器中运行的任务：计划并跟踪的，以确保其完成。

对于此项目，cron作业是一个运行容器。

为Twitter API凭证创建机密

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

kubectl create secret generic twitter-creds \     
         --from-literal=TWITTER_ACCESS_SECRET=
    
      \     
         --from-literal=TWITTER_ACCESS_TOKEN=
     
       \     
         --from-literal=TWITTER_API_KEY=
      
        \     
         --from-literal=TWITTER_API_SECRET=
       
         \     
         --from-literal=TWITTER_USER=

创建计划任务

最后，是时候创建cron作业以收集统计信息了。不幸的是， kubectl无法直接创建cron作业，因此必须再次在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 cron作业的关键部分显而易见。 cron作业规范包含描述Kubernetes工作运行jobTemplate。 在这种情况下，作业由一个容器组成，该容器具有Twitter和InfluxDB凭据的秘密，这些秘密使用部署中使用的envFrom作为环境变量共享。

该作业使用来自Docker Hub的自定义映像clcollins / twittergraph：1.0 。该图像只是Python 3.6，其中包含的。（如果您想自己构建映像，则可以按照GitHub存储库中中的说明使用构建。）

包装作业模板规范是cron作业规范选项。可以说，除了工作本身之外，最重要的部分是时间表 ，这里设置为永远每3分钟运行一次。另一个重要的位是concurrencyPolicy ，它设置为replace ，因此，如果在开始新作业时前一个作业仍在运行，则运行旧作业的吊舱将被销毁并替换为新的吊舱。

使用kubectl create -f cronjob.yml命令创建cron作业：

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

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

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

注意：将时间表设置为* / 3 * * * *时，Kubernetes不会立即开始新作业。第一个阶段将等待三分钟。如果您希望看到即时的结果，则可以使用kubectl edit cronjob twittergraph编辑cron作业，（临时）将时间表更改为* * * * *以每分钟运行一次。只是不要忘记在完成后将其更改回去。

成功！

应该是这样。如果您正确执行了所有步骤，则将拥有InfluxDB数据库，从您的Twitter帐户收集统计信息的cron作业，以及用于查看数据的Grafana部署。对于Kubernetes或OpenShift的生产集群或云部署，请访问LoadBalancer IP以使用您之前使用GF_SECURITY_ADMIN_USER和GF_SECURITY_ADMIN_PASSWORD设置的凭据登录Grafana 。登录后，从屏幕左上方的“主页”下拉列表中选择TwitterGraph仪表板。您应该看到下图所示的图像，其中包括您的关注者，您关注的人，状态更新，喜欢和列表的当前计数。一开始可能有点无聊，但是如果您让它继续运行，随着时间的流逝并收集更多数据，则图表将开始看起来更加有趣并提供更多有用的数据！