运行和部署控制器

Optional

如果选择对 API 定义进行任何更改，请在继续之前生成类似于 CR 或 CRD 的清单。

make manifests

为了测试控制器，我们可以在集群上本地运行它。不过，在此之前，我们需要安装我们的 CRD，按照 快速启动 的指南。这将自动使用 controller-tools 更新 YAML 清单（如果需要的话）：

make install

现在我们已经安装了CRD（自定义资源定义），可以在我们的集群上运行控制器。这将使用我们连接到集群时的凭据，因此我们暂时不需要担心RBAC（基于角色的访问控制）。

在另一个终端中运行

export ENABLE_WEBHOOKS=错误
make run

您应该看到控制器关于启动的日志，但它暂时不会执行任何操作。

此时，我们需要一个 CronJob 进行测试。让我们在 config/samples/batch_v1_cronjob.yaml 中写一个示例，并使用它：

apiVersion: batch.tutorial.kubebuilder.io/v1
kind: CronJob
metadata:
  labels:
    app.kubernetes.io/name: project
    app.kubernetes.io/managed-by: kustomize
  name: cron作业示例
spec:
  日程安排: "*/1 * * * *"
  启动截止时间（秒）: 60
  并发策略: 允许 # 显式指定，但允许也是默认值。
  工作模板:
    spec:
      template:
        spec:
          容器:
          - name: 你好
            image: busybox
            args:
            - /bin/sh
            - -c
            - 日期; 在Kubernetes集群中打招呼。
          重启策略: 失败时
  

kubectl create -f config/samples/batch_v1_cronjob.yaml

此时，你应该会看到一阵忙碌的活动。如果你观察这些变化，你应该能看到你的定时任务在运行，并更新状态：

kubectl get cronjob.batch.tutorial.kubebuilder.io -o yaml
kubectl get job

现在我们知道它可以正常工作，我们可以在集群中运行它。停止 make run 调用，然后运行

make docker-build docker-push IMG=<some-registry>/<project-name>:tag
make deploy IMG=<some-registry>/<project-name>:tag

如果我们像之前一样再次列出定时任务，我们应该能看到控制器再次正常运行！