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

统计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。

如果您选择进一步研究，则包含的文件可以用作Tweepy的简介， Tweepy是“用于访问Twitter API的易于使用的Python模块”，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 cron作业按计划轮询Twitter，因此InfluxDB非常适合保存数据。

DockerHub上由Docker维护的InfluxDB映像在该项目中可以正常工作。它可以与Kubernetes和OKD一起使用。

创建部署

Kubernetes部署描述了所需的资源状态。对于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:         <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

`使用密码配置InfluxDB凭据`

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

Kuberenetes机密是一种存储敏感信息（例如密码）并将其作为环境变量或装入的卷注入运行中的容器的方法。这对于存储数据库凭据和连接信息非常理想，既可以配置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:       <none>

        Annotations:  <none>

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时丢失。需要一个PersistentVolume来永久存储数据。

为了在Kubernetes集群中获得持久性存储，将创建一个PersistentVolumeClaim （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无法互相交谈。需要Kubernetes服务将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:       <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可以通过该IP地址与InfluxDB通信。 “端点”是侦听连接的容器的IP和端口。该服务会将流量路由到内部群集IP到容器本身。

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

`设置Grafana`

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

与InfluxDB一样， DockerHub上的正式Grafana映像可与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 ConfigMap与机密相似，吊舱可以以相同的方式使用它，但是它们不存储在Kubernetes中混淆的信息。配置映射对于将配置文件或变量添加到Pod的容器中很有用。

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

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

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

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

在包含仓库内容的目录中，使用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:       <none>

        Annotations:  <none>

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

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

每个文件名都应存储为键，其内容应存储为值（例如上面的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: # <string, required> 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   <pending>     80:31235/TCP   9m35s

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

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

`创建cron作业`

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

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

`为Twitter API凭证创建机密`

cron作业使用您的Twitter API凭据连接到API，并从容器内的环境变量中提取统计信息。创建一个秘密来存储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>

`创建计划任务`

最后，是时候创建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，其中包含适用于TwitterGraph的app.py Python脚本。（如果您想自己构建映像，则可以按照GitHub存储库中BUILDING.md中的说明使用Source-To-Image构建映像。）

包装作业模板规范是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:                <none>

        Schedule:                   */3 * * * *

        Concurrency Policy:         Replace

        Suspend:                    False

        Starting Deadline Seconds:  <unset>

注意：将时间表设置为* / 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仪表板。您应该看到下图所示的图像，其中包括您的关注者，您关注的人，状态更新，喜欢和列表的当前计数。一开始可能有点无聊，但是如果您让它继续运行，随着时间的流逝并收集更多数据，则图表将开始看起来更加有趣并提供更多有用的数据！

`从这往哪儿走`

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

`接下来要读什么`

翻译自: https://opensource.com/article/19/2/deploy-influxdb-grafana-kubernetes

统计twitter帖子