【云原生】Kubernetes核心技术（下）

博主昵称：跳楼梯企鹅
博主主页面链接：博主主页传送门

博主专栏页面连接：专栏传送门--网路安全技术
创作初心：本博客的初心为与技术朋友们相互交流，每个人的技术都存在短板，博主也是一样，虚心求教，希望各位技术友给予指导。
博主座右铭：发现光，追随光，成为光，散发光;
博主研究方向：渗透测试、机器学习 ;
博主寄语：感谢各位技术友的支持，您的支持就是我前进的动力 ;

本篇文章分为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:       
Annotations:  
 
Data
====
appdatadir:
----
/var/data
apploglevel:
----
info
Events:  

 （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  --help" for more information about a given command.
Use "kubectl options" for a list of global command-line options (applies to all
commands).

完