https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/
可以通过查看event看到.
类似linux定时任务.
先决: crontab需要用到这个版的api,将下面的添加到api的配置
--runtime-config=batch/v2alpha1=true
创建crontab
apiVersion: batch/v2alpha1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
args:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: OnFailure
kubectl create -f crontab.yml
也可以这样运行一个crontab
kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster"
cronjob "hello" created
After creating the cron job, get its status using this command:
$ kubectl get cronjob hello
NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE
hello */1 * * * * False 0 <none>
As you can see above, there’s no active job yet, and no job has been scheduled, either.
Watch for the job to be created in around one minute:
$ kubectl get jobs --watch
NAME DESIRED SUCCESSFUL AGE
hello-4111706356 1 1 2s
Now you’ve seen one running job scheduled by “hello”. We can stop watching it and get the cron job again:
$ kubectl get cronjob hello
NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE
hello */1 * * * * False 0 Mon, 29 Aug 2016 14:34:00 -0700
You should see that “hello” successfully scheduled a job at the time specified in LAST-SCHEDULE. There are currently 0 active jobs, meaning that the job that’s scheduled is completed or failed.
Now, find the pods created by the job last scheduled and view the standard output of one of the pods. Note that your job name and pod name would be different.
# Replace "hello-4111706356" with the job name in your system
$ pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items..metadata.name})
$ echo $pods
hello-4111706356-o9qcm
$ kubectl logs $pods
Mon Aug 29 21:34:09 UTC 2016
Hello from the Kubernetes cluster
删除crontab.
有个疑问,就是crontab没执行起来,
todo:
滚动升级
pod调用
还有个没太理解的问题就是dashboard, dashboard访问的是api的https接口?如果集群没配证书怎么搞?
这里懂了
dashboard的yml里有配置api地址的地方,这里架构选用单独一台nginx做vip即api地址.
+-------------+ user +-------------+ service +-------------+
| | authentication | | authentication | |
| browser +------------------->+ apiserver +<-------------------+ dashboard |
| | | | | |
+-------------+ +-------------+ +-------------+
In the diagram below you can see the full authentication flow with all options, starting with the browser on the lower left hand side.
Workstation Kubernetes
+------------------+ +----------------------------------------------------+
| | | |
| | | |
| +------------+ | | +------------+ apiserver +------------+ |
| | | | authentication with kubectl | | | proxy | | |
| | kubectl +------------------------------------>+ apiserver +------------------->+ dashboard | |
| | proxy | | | | | | | |
| | | | | | | | | |
| +--------+---+ | | | | | | |
| ^ | +------>+ | service account/ | | |
| localhost| | | | | | kubeconfig | | |
| | | | | | +<-------------------+ | |
| +--------+---+ | | | | | | | |
| | | | direct access | | +------------+ +------+-----+ |
| | browser +-----------------------------+ | | |
| | | | | | |
| | +----------------------------------------------------------------------------->O |
| +------------+ | bypass apiserver | NodePort |
| | | |
| | | |
+------------------+ +----------------------------------------------------+