1.4kubernetes基本概念和术语(5) -- job、v

欢迎各位读者评论留言，共同学习，共同进步。
《kubernetes权威指南》笔记
1.4kubernetes基本概念和术语(1)
1.4kubernetes基本概念和术语(2)
1.4kubernetes基本概念和术语(3)
1.4kubernetes基本概念和术语(4)

10.Job

• 用于批处理，批处理任务通常并行（或者串行）启动多个计算进程去处理一批工作项（work item），在处理完成后，整个批处理任务结束。
• Job也是一种特殊的Pod副本自动控制器，同时Job控制Pod副本与RC等控制器的工作机制的差别：
  （1）Job控制的Pod是短暂运行的，可以看做是只运行一次的一组Docker容器。Job控制的所有Pod副本结束，Job也随之结束。
  （2）Job在实现方式上与RC等副本控制器不同，Job生成的Pod副本是不能自动重启的，对应Pod副本的RestartPoliy都被设置为Never。在1.5版本之后提供了类似crontab的定时任务——CronJob，解决了某些批处理任务需要定时反复执行的问题。
  （3）Job所控制的Pod副本的工作模式能够多实例并行计算。

11.Volume

• 与Docker 中Volume 区别：
  a. Kubernetes的Volume概念、用途和目的与Docker的Volume比较类似，但两者不能等价。
  b. 首先，Kubernetes中的Volume被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下；
  其次，Kubernetes中的Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终止或者重启时，Volume中的数据也不会丢失。
  最后，Kubernetes支持多种类型的Volume，例如GlusterFS、Ceph等先进的分布式文件系统。

• Volume的使用：
  a.方法1：在Pod上声明一个Volume，然后在容器里引用该Volume并挂载（Mount）到容器里的某个目录上

  
  image.png

b. 除了可以让一个Pod里的多个容器共享文件、让容器的数据写到宿主机的磁盘上或者写文件到网络存储中，Kubernetes的Volume还扩展出了一种非常有实用价值的功能，即容器配置文件集中化定义与管理，这是通过ConfigMap这种新的资源对象来实现的。

• Volume 的种类

• 1. emptyDir:
     在Pod分配到Node时创建的,无需配置路径，在Pod移除时emptyDir中的数据也会被永久删除。
     用途：◎ 临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保留。
     ◎ 长时间任务的中间过程CheckPoint的临时保存目录。
     ◎ 一个容器需要从另一个容器中获取数据的目录（多容器共享目录）。
     目前无法控制存储介质，如果kubelet的配置是使用硬盘，那么所有emptyDir都将被创建在该硬盘上。Pod在将来可以设置emptyDir是位于硬盘、固态硬盘上还是基于内存的tmpfs上。
• 2. hostPath
     hostPath为在Pod上挂载宿主机上的文件或目录。
     用途：◎ 容器应用程序生成的日志文件需要永久保存时，可以使用宿主机的高速文件系统进行存储。
     ◎ 需要访问宿主机上Docker引擎内部数据结构的容器应用时，可以通过定义hostPath为宿主机/var/lib/docker目录，使容器内部应用可以直接访问Docker的文件系统。
     注意：◎ 在不同的Node上具有相同配置的Pod，可能会因为宿主机上的目录和文件不同而导致对Volume上目录和文件的访问结果不一致。
     ◎ 如果使用了资源配额管理，则Kubernetes无法将hostPath在宿主机上使用的资源纳入管理。

12. Persistent Volume

• Volume是被定义在Pod上的，属于计算资源的一部分，而实际上，网络存储是相对独立于计算资源而存在的一种实体资源
• PV可以被理解成Kubernetes集群中的某个网络存储对应的一块存储，它与Volume类似。

• 注意：◎ PV只能是网络存储，不属于任何Node，但可以在每个Node上访问。
  ◎ PV并不是被定义在Pod上的，而是独立于Pod之外定义的。
  ◎ PV目前支持的类型包括：gcePersistentDisk、AWSElasticBlockStore、AzureFile、AzureDisk、FC（Fibre Channel）、Flocker、NFS、iSCSI、RBD（Rados Block Device）、CephFS、Cinder、GlusterFS、VsphereVolume、Quobyte Volumes、VMware Photon、Portworx Volumes、ScaleIOVolumes和HostPath（仅供单机测试）。

  
  image.png

• PV的accessModes属性，目前有以下类型。
  ◎ ReadWriteOnce：读写权限，并且只能被单个Node挂载。
  ◎ ReadOnlyMany：只读权限，允许被多个Node挂载。
  ◎ ReadWriteMany：读写权限，允许被多个Node挂载。
  如果某个Pod想申请某种类型的PV，则首先需要定义一个PersistentVolumeClaim对象：

  
  image.png
  

  然后，在Pod的Volume定义中引用上述PVC即可：

  
  image.png
• PV的状态。PV是有状态的对象，它的状态有以下几种。
  ◎ Available：空闲状态。
  ◎ Bound：已经绑定到某个PVC上。
  ◎ Released：对应的PVC已经被删除，但资源还没有被集群收回。
  ◎ Failed：PV自动回收失败。

13. Namespace

• Namespace在很多情况下用于实现多租户的资源隔离。
  Namespace通过将集群内部的资源对象“分配”到不同的Namespace中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。
• 如果不加参数，则kubectl get命令将仅显示属于default命名空间的资源对象。
• 当给每个租户创建一个Namespace来实现多租户的资源隔离时，还能结合Kubernetes的资源配额管理，限定不同租户能占用的资源，例如CPU使用量、内存使用量等。

14. Annotation

• Annotation与Label的异同：
  Annotation（注解）与Label类似，也使用key/value键值对的形式进行定义。
  不同的是Label具有严格的命名规则，它定义的是Kubernetes对象的元数据（Metadata），并且用于Label Selector。
  Annotation则是用户任意定义的附加信息，以便于外部工具查找。在很多时候，Kubernetes的模块自身会通过Annotation标记资源对象的一些特殊信息。
• 通常来说，用Annotation来记录的信息如下。
  ◎ build信息、release信息、Docker镜像信息等，例如时间戳、release id号、PR号、镜像Hash值、DockerRegistry地址等。
  ◎ 日志库、监控库、分析库等资源库的地址信息。
  ◎ 程序调试工具信息，例如工具名称、版本号等。
  ◎ 团队的联系信息，例如电话号码、负责人名称、网址等。

15. ConfigMap

• Docker 的配置化管理：
  docker 通过将程序、依赖库、数据及配置文件“打包固化”到一个不变的镜像文件中的做法，解决了应用的部署的难题，但这同时带来了棘手的问题，即配置文件中的参数在运行期如何修改的问题。
  docker的解决办法： ◎ 在运行时通过容器的环境变量来传递参数；
  ◎ 通过Docker Volume将容器外的配置文件映射到容器内。
  缺点：（1）写入（修改）多台服务器上的某个指定文件，并确保这些文件保持一致，都是一个很难完成的目标。
  （2）在大多数情况下，我们都希望能集中管理系统的配置参数，而不是管理一堆配置文件。

Kubernetes的做法：

• 通过KubernetesConfigMap资源对象，key=value可以作为Map表中的一个项，整个Map的数据可以被持久化存储在Kubernetes的Etcd数据库中，然后提供API以方便Kubernetes相关组件或客户应用CRUD操作这些数据。
• Kubernetes提供了一种内建机制，将存储在etcd中的ConfigMap通过Volume映射的方式变成目标Pod内的配置文件，不管目标Pod被调度到哪台服务器上，都会完成自动映射。
• 如果ConfigMap中的key-value数据被修改，则映射到Pod中的“配置文件”也会随之自动更新。
  于是，Kubernetes ConfigMap就成了分布式系统中最为简单（使用方法简单，但背后实现比较复杂）且对应用无侵入的配置中心。

总结： ConfigMap的方法： 用ETCD 全局存储配置，通过Mount挂在Pod上，配置文件更新时，对应Pod也会更新配置。