博主昵称：跳楼梯企鹅
博主主页面链接：博主主页传送门博主专栏页面连接：专栏传送门--网路安全技术
创作初心：本博客的初心为与技术朋友们相互交流，每个人的技术都存在短板，博主也是一样，虚心求教，希望各位技术友给予指导。
博主座右铭：发现光，追随光，成为光，散发光;
博主研究方向：渗透测试、机器学习 ;
博主寄语：感谢各位技术友的支持，您的支持就是我前进的动力 ;
本篇文章分为3次分享完
前两部分已经分享了，今天来完结吧~
七·、Job
1.快速了解
Kubernetes jobs主要是针对短时和批量的工作负载。它是为了结束而运行的，而不是像deployment、replicasets、replication controllers和DaemonSets等其他对象那样持续运行。
Kubernetes Jobs会一直运行到Job中指定的任务完成。也就是说，如果pods给出退出代码0，那么Job就会退出。而在正常的Kubernetes中，无论退出代码是什么，deployment对象在终止或出现错误时都会创建新的pod，以保持deployment的理想状态。
在job运行过程中，如果托管pod的节点发生故障，Job pod将被自动重新安排到另一个节点。
2. 实例
（1）批处理任务： 比如说你想每天运行一次批处理任务，或者在指定日程中运行。它可能是像从存储库或数据库中读取文件那样，将它们分配给一个服务来处理文件。
（2）运维/ad-hoc任务： 比如你想要运行一个脚本/代码，该脚本/代码会运行一个数据库清理活动，甚至备份一个Kubernetes集群。
3.创建Kubernetes Job
使用自定义的Docker镜像创建一个job.yaml文件，参数传递给docker ENTRYPOINT脚本。
apiVersion: batch/v1
使用kubectl创建一个job.yaml文件的job
kubectl apply -f job.yam
使用kubectl检查job的状态
kubectl get jobs
使用kubectl获取pod列表
kubectl get po
使用kubectl获取job pod 日志。使用你在输出中看到的Pod名称替换原本的Pod名称。
kubectl logs kubernetes-job-example-bc7s9 -f
如下输出：
并行运行多Job pods
当一个job被部署后，你可以让它在多个Pod上并行运行：
completions: 6
带有那些参数的manifest：
apiVersion: batch/v1
为Kubernetes Job生成随机名称
你不能从一个job manifest文件中创建多个job
apiVersion: batch/v1
4.运行一次性容器
启动这个job
[root@k8s-master k8s]# kubectl apply -f myjob.yml
job.batch/myjob created
kubectl get job 查看这个job
[root@k8s-master k8s]# kubectl get job
NAME COMPLETIONS DURATION AGE
myjob 1/1 23s 3m45s
completions为 1/1 表示成功运行了这个job
kubectl get pod 查看pod的状态
[root@k8s-master k8s]# kubectl get pod
NAME READY STATUS RESTARTS AGE
myjob-29qlw 0/1 Completed 0 4m5s
看到 状态为Completed表示这个job已经运行完成
kubectl logs 命令查看这个 pod的日志
[root@k8s-master k8s]# kubectl logs myjob-29qlw
hello k8s job!
5.job controller源码
JobController 结构
type JobController struct {
// 访问 kube-apiserver 的client
// 需要查询 job、pod 等元数据信息
kubeClient clientset.Interface
// pod 控制器，用于创建和删除pod使用
podControl controller.PodControlInterface
// 用于更新 job status
updateHandler func(job *batch.Job) error
// job controller 核心接口，用于 sync job
syncHandler func(jobKey string) (bool, error)
// job controller 在启动时会对 job & pod 先进行同步
// 用于判断是否已经对 pod 同步过
podStoreSynced cache.InformerSynced
// 用于判断是否已经对 job 同步过
jobStoreSynced cache.InformerSynced
// expectations cache，记录该job下pods的adds & dels次数，
// 并提供接口进行调整，已达到期望值。
expectations controller.ControllerExpectationsInterface
// jobLister 用于获取job元数据及根据pod的labels来匹配jobs
// 该controller 会使用到的接口如下:
// 1. GetPodJobs(): 用于根据pod反推jobs
// 2. Get(): 根据namespace & name 获取job 元数据
jobLister batchv1listers.JobLister
// podStore 提供了接口用于获取指定job下管理的所有pods
podStore corelisters.PodLister
// Jobs queue
// job controller通过kubeClient watch jobs & pods的数据变更，
// 比如add、delete、update，来操作该queue。
// 并启动相应的worker，调用syncJob处理该queue中的jobs。
queue workqueue.RateLimitingInterface
// jobs的相关events,通过该recorder进行广播
recorder record.EventRecorder
}
startJobController()
func startJobController(ctx ControllerContext) (bool, error) {
// 在启动job controller之前，判断下job 是否有配置生效
// 用户可以在创建k8s clusters时，通过修改kube-apiserver --runtime-config配置想要生效的 resource
if !ctx.AvailableResources[schema.GroupVersionResource{Group: "batch", Version: "v1", Resource: "jobs"}] {
return false, nil
}
// 初始化 JobController结构，并Run
// Run的时候指定了gorutinue的数量，每个gorutinue 就是一个worker
go job.NewJobController(
ctx.InformerFactory.Core().V1().Pods(),
ctx.InformerFactory.Batch().V1().Jobs(),
ctx.ClientBuilder.ClientOrDie("job-controller"),
).Run(int(ctx.ComponentConfig.JobController.ConcurrentJobSyncs), ctx.Stop)
return true, nil
}
NewJobController()
func NewJobController(podInformer coreinformers.PodInformer, jobInformer batchinformers.JobInformer, kubeClient clientset.Interface) *JobController {
// 初始化event broadcaster
// 用于该controller 发送job 相关的events
eventBroadcaster := record.NewBroadcaster()
// 注册打印event信息的function
// eventBroadcaster.StartEventWatcher()会创建gorutinue并开始watch event,
// 根据注册的eventHandler轮询处理每个event，这里就是通过glog.Infof打印日志
eventBroadcaster.StartLogging(glog.Infof)
// EventSinkImpl 包含了一个EventInterface, 实现了Create/Update/Delete/Get/Watch/Patch..等等操作
// 这一步跟上面一样，也是通过eventBroadcaster.StartEventWatcher() 注册了EventInterface实现，
// 用来从指定的eventBroadcaster接收event，并发送给指定的接收器。
// k8s event实现可以多带带进行源码分析，值得学习下。
eventBroadcaster.StartRecordingToSink(&v1core.EventSinkImpl{Interface: kubeClient.CoreV1().Events("")})
// kubernetes 内部的限流策略
// 对apiserver来说，每个controller及scheduler都是client，所以内部的限流策略也至关重要。
if kubeClient != nil && kubeClient.CoreV1().RESTClient().GetRateLimiter() != nil {
metrics.RegisterMetricAndTrackRateLimiterUsage("job_controller", kubeClient.CoreV1().RESTClient().GetRateLimiter())
}
// 初始化JobController
jm := &JobController{
// 连接kube-apiserver的client
kubeClient: kubeClient,
// podControl，用于manageJob()中创建和删除pod
podControl: controller.RealPodControl{
KubeClient: kubeClient,
Recorder: eventBroadcaster.NewRecorder(scheme.Scheme, v1.EventSource{Component: "job-controller"}),
},
// 维护的期望状态下的Pod Cache，并且提供了修正该Cache的接口
// 比如会存jobs 下pods 的adds & dels 值,并提供了接口修改这两个值。
expectations: controller.NewControllerExpectations(),
// jobs queue, 后面会创建对应数量的workers 从该queue 中处理各个jobs。
queue: workqueue.NewNamedRateLimitingQueue(workqueue.NewItemExponentialFailureRateLimiter(DefaultJobBackOff, MaxJobBackOff), "job"),
// event recorder,用于发送job 相关的events
recorder: eventBroadcaster.NewRecorder(scheme.Scheme, v1.EventSource{Component: "job-controller"}),
}
// 注册jobInformer 的Add、Update、Delete 函数
// 该controller 获取到job 的Add、Update、Delete事件之后，会调用对应的function
// 这些function 的核心还是去操作了上面的queue，让syncJob 处理queue 中的jobs
jobInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{
AddFunc: func(obj interface{}) {
jm.enqueueController(obj, true)
},
UpdateFunc: jm.updateJob,
DeleteFunc: func(obj interface{}) {
jm.enqueueController(obj, true)
},
})
// 上面结构中已经有介绍
jm.jobLister = jobInformer.Lister()
jm.jobStoreSynced = jobInformer.Informer().HasSynced
// 注册 podInformer 的Add、Update、Delete 函数
// job 最终是依托了pod 去运行，所以相关的pods 事件也需要关心。
// 该podInformer 会监听所有的pods 变更事件，所以函数中都会去判断该pod 的containerRef是否是“job”，
// 如果是的话再更新对应的expectations & queue, 触发syncJob进行处理。
podInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{
AddFunc: jm.addPod,
UpdateFunc: jm.updatePod,
DeleteFunc: jm.deletePod,
})
// 上面结构中已经有介绍
jm.podStore = podInformer.Lister()
jm.podStoreSynced = podInformer.Informer().HasSynced
// 注册更新job status的函数
jm.updateHandler = jm.updateJobStatus
// 注册sync job handler
// 核心实现
jm.syncHandler = jm.syncJob
return jm
}
Run()
// Run the main goroutine responsible for watching and syncing jobs.
func (jm *JobController) Run(workers int, stopCh <-chan struct{}) {
defer utilruntime.HandleCrash()
defer jm.queue.ShutDown()
glog.Infof("Starting job controller")
defer glog.Infof("Shutting down job controller")
// 每次启动都会先等待Job & Pod cache 是否有同步过，即指queue是否已经同步过数据，
// 因为每个worker干的活都是从queue中获取，所以只有queue有数据才应该继续往下创建worker。
if !controller.WaitForCacheSync("job", stopCh, jm.podStoreSynced, jm.jobStoreSynced) {
return
}
// 创建指定数量的gorutinue
// 每个gorutinue 执行worker，每个worker 执行完了之后sleep 1s，然后继续循环执行
for i := 0; i < workers; i++ {
go wait.Until(jm.worker, time.Second, stopCh)
}
<-stopCh
}
6.cronJob
cronJob是基于时间进行任务的定时管理：
在特定的时间点运行任务
反复在指定的时间点运行任务：比如定时进行数据库备份，定时发送电子邮件等等。
八、ConfigMap
为了解决传统容器中配置的挂载、变更、管理等问题，在k8s中引入了一个叫做configmap的资源对象，在configmap中，各个配置项都是以key-value的方式存在的，value的数据可以是一个配置文件的内容，这些配置项被保存在k8s使用的持久化存储etcd中。这样就形成了一个k8s中的配置中心，可以独立的对configmap中的数据进行修改，然后将configmap挂载到pod中进行使用，可以以env的方式，也可以以配置文件的方式在pod中进行引用，这样配置和pod就实现了解耦，都是k8s中独立的资源对象。
个人理解：configmap是k8s中的应用配置管理方案。
1. ConfigMap基础命令
kubectl create configmap test --from-file=/root/yaml/nginx.yaml
#将/root/yaml/nginx.yaml文件写入configmap 名字为test(存储配置文件)
kubectl create configmap test02 --from-file=/root/yaml/
#将/root/yaml/目录下的文件写入configmap，configmap 名字为test02
kubectl create configmap test01 --from-literal=MYSQL_ROOT_PASSWORD=123456
#变量储存到configmap，变量名为MYSQL_ROOT_PASSWORD，值为123456，可以跟更多变量，在尾部加--from-literal=key=value 即可
kubectl describe configmaps test
#查询上面的结果
2. configmap对象
（1）定义环境变量
kubectl apply -f - <<'eof'
apiVersion: v1
kind: ConfigMap
metadata:
name: cm-vars
data:
apploglevel: info
appdatadir: /var/data
eof
（2）执行创建configmap
[root@root ~]# kubectl apply -f - <<'eof'
> apiVersion: v1
> kind: ConfigMap
> metadata:
> name: cm-vars
> data:
> apploglevel: info
> appdatadir: /var/data
> eof
configmap/cm-vars created
[root@root ~]# kubectl get cm
NAME DATA AGE
cm-vars 2 5s
kube-root-ca.crt 1 38d
[root@root ~]#
（3）查看configmap
[root@root ~]# kubectl get cm cm-vars -o yaml
apiVersion: v1
data:
appdatadir: /var/data
apploglevel: info
kind: ConfigMap
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","data":{"appdatadir":"/var/data","apploglevel":"info"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"cm-vars","namespace":"default"}}
creationTimestamp: "2022-01-10T07:31:05Z"
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:data:
.: {}
f:appdatadir: {}
f:apploglevel: {}
f:metadata:
f:annotations:
.: {}
f:kubectl.kubernetes.io/last-applied-configuration: {}
manager: kubectl-client-side-apply
operation: Update
time: "2022-01-10T07:31:05Z"
name: cm-vars
namespace: default
resourceVersion: "11021769"
selfLink: /api/v1/namespaces/default/configmaps/cm-vars
uid: c513d39b-c128-46d3-9eb7-78da20ec47f2
[root@root ~]# kubectl describe cm cm-vars
Name: cm-vars
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
appdatadir:
----
/var/data
apploglevel:
----
info
Events: <none>
（4）使用configmap
apiVersion: v1
kind: ConfigMap
metadata:
name: test04
data:
MYSQL_ROOT_PASSWORD: '123456'
#定义一个变量，值类型为字符串，所以需要加引号
my.cnf: |
[mysqld]
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
datadir = /var/lib/mysql
character-set-server = utf8
log-error = /var/log/mysqld.log
# 中继日志
relay-log=mysql-relay-bin
replicate-wild-ignore-table=mysql.%
replicate-wild-ignore-table=test.%
replicate-wild-ignore-table=information_schema.%
---
kind: Deployment
apiVersion: apps/v1
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:5.7
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /opt #挂载到那个目录
name: test
command:
- sh
- -c
- sleep 100
volumes:
- name: test #存储卷的名称
configMap:
name: test04 #configmap名字
items:
- key: my.cnf #configmap 内文件
path: my.cnf #configmap挂载到容器内的相对路径
九、Secrets
secret是k8s中用来存储敏感认证信息的一种重要资源，大致可以分为三种类型：docker-registry，generic和tls，从名称上就可以看出来，分别用于存储镜像仓库认证信息，一般信息和证书信息。其中generic类型的最常用，比较典型的就是用来存放数据库的认证信息。
说白了就是一种安全机制
1.Secret 有三种类型
（1）Service Account ：用来访问 Kubernetes API，由 Kubernetes 自动创建，用于被 serviceaccount 引用。serviceaccout 创建时 Kubernetes 会默认创建对应的 secret。Pod 如果使用了 serviceaccount，对应的 secret 会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中。
（2）Opaque ：base64编码格式的Secret，用来存储密码、密钥等
（3）kubernetes.io/dockerconfigjson ：用来存储私有 docker registry 的认证信息
2.创建secret
[root@root pod]# kubectl create secret --help
Create a secret using specified subcommand.
Available Commands:
docker-registry Create a secret for use with a Docker registry
generic Create a secret from a local file, directory or literal value
tls Create a TLS secret
Usage:
kubectl create secret [flags] [options]
Use "kubectl <command> --help" for more information about a given command.
Use "kubectl options" for a list of global command-line options (applies to all
commands).
