kubernetes资源对象--pod和job
pod
Pod是K8S的最小操作单元，一个Pod可以由一个或多个容器组成；
整个K8S系统都是围绕着Pod展开的，比如如何部署运行Pod、如何保证Pod的数量、如何访问Pod等。
特点
Pod是能够被创建、调度和管理的最小单元；
每个Pod都有一个独立的IP；
一个Pod由一个或多个容器构成，并共享命名空间和共享存储等；Pod所有容器在同一个Node上；
容器生命周期管理；
对资源使用进行限制，resources（requests、limits）；
对容器进行探测：livenessProbe；
集群内的Pod之间都可以任意访问，这一般是通过一个二层网络来实现的。
Pod与容器
在Docker中，容器是最小的处理单元，增删改查的对象是容器，容器是一种虚拟化技术，容器之间是隔离的，隔离是基于Linux Namespace实现的。
而在K8S中，Pod包含一个或者多个相关的容器，Pod可以认为是容器的一种延伸扩展，一个Pod也是一个隔离体，而Pod内部包含的一组容器又是共享的（包括PID、Network、IPC、UTS）。除此之外，Pod中的容器可以访问共同的数据卷来实现文件系统的共享。
资源请求与限制
创建Pod时，可以指定计算资源（目前支持的资源类型有CPU和内存），即指定每个容器的资源请求（Request）和资源限制（Limit），资源请求是容器所需的最小资源需求，资源限制则是容器不能超过的资源上限。关系是： 0<=request<=limit<=infinity
Pod的资源请求就是Pod中所有容器资源请求之和。K8S在调度Pod时，会根据Node中的资源总量（通过cAdvisor接口获得），以及该Node上已使用的计算资源，来判断该Node是否满足需求。
资源请求能够保证Pod有足够的资源来运行，而资源限制则是防止某个Pod无限制地使用资源，导致其他Pod崩溃。特别是在公有云场景，往往会有恶意软件通过抢占内存来攻击平台。
具体配置请见http://blog.csdn.net/liyingke112/article/details/77452630
一pod多容器
Pod主要是在容器化环境中建立一个面向应用的“逻辑主机”模型，它可以包含一个或多个相互间紧密联系的容器。当其中任一容器异常时，该Pod也随之异常。
一pod多容器，让多个同应用的单一容器整合到一个类虚拟机中，使其所有容器共用一个vm的资源，提高耦合度，从而方便副本的复制，提高整体的可用性。
一pod多容器的优势：
同个Pod下的容器之间能更方便的共享数据和通信，使用相同的网络命名空间、IP地址和端口区间，相互之间能通过localhost来发现和通信。
在同个Pod内运行的容器共享存储空间（如果设置），存储卷内的数据不会在容器重启后丢失，同时能被同Pod下别的容器读取。
相比原生的容器接口，Pod通过提供更高层次的抽象，简化了应用的部署和管理，不同容器提供不同服务。Pod就像一个管理横向部署的单元，主机托管、资源共享、协调复制和依赖管理都可以自动处理。
yaml文件格式请见http://blog.csdn.net/liyingke112/article/details/76155428
Job
概念
在有些场景下，是想要运行一些容器执行某种特定的任务，任务一旦执行完成，容器也就没有存在的必要了。在这种场景下，创建pod就显得不那么合适。于是就是了Job，Job指的就是那些一次性任务。通过Job运行一个容器，当其任务执行完以后，就自动退出，集群也不再重新将其唤醒。
从程序的运行形态上来区分，可以将Pod分为两类：长时运行服务（jboss、mysql等）和一次性任务（数据计算、测试）。RC创建的Pod都是长时运行的服务，Job多用于执行一次性任务、批处理工作等，执行完成后便会停止（status.phase变为Succeeded）。
yaml配置参数说明
重启策略
支持两种重启策略：
OnFailure:在出现故障时其内部重启容器，而不是创建。
Never:会在出现故障时创建新的，且故障job不会消失。
设置超时
job执行超时时间可以通过spec.activeDeadlineSeconds来设置，超过指定时间未完成的job会以DeadlineExceeded原因停止
并行
.spec.completions：这个job运行pod的总次数
.spec.parallelism：并发数，每次同时运行多少个pod
当completions少于parallelism，parallelism的值为completions
可以使用kubectl scale命令来增加或者减少completions的值
pod selector
job同样可以指定selector来关联pod。需要注意的是job目前可以使用两个API组来操作，batch/v1和extensions/v1beta1。当用户需要自定义selector时，使用两种API组时定义的参数有所差异。
使用batch/v1时，用户需要将jod的spec.manualSelector设置为true，才可以定制selector。默认为false。
使用extensions/v1beta1时，用户不需要额外的操作。因为extensions/v1beta1的spec.autoSelector默认为false，该项与batch/v1的spec.manualSelector含义正好相反。换句话说，使用extensions/v1beta1时，用户不想定制selector时，需要手动将spec.autoSelector设置为true。
例子
kubectl delete -f kube-lykops-job.yaml
cat << EOF > kube-lykops-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
labels:
app: job
project: lykops
version: v1
name: lykops-job
namespace: default
spec:
completions: 50
parallelism: 5
template:
metadata:
labels:
app: job
job-name: lykops-job
project: lykops
version: v1
name: lykops-job
spec:
containers:
- command: ['sleep','60']
image: web:apache
name: lykops-job
restartPolicy: Never
EOF
kubectl create -f kube-lykops-job.yaml
细节
job执行完后，不会自动启动一个新的pod，pod也不会被自动删除。
使用kubectl get pod无法显示执行完的job的pod，需要添加参数—all-show或者-a，kubectl get pods -a。