13518219792
Pod是一组紧密关联的容器集合，支持多个容器在一个Pod 里共 享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式完成服务，是Kubernetes调度的基本单位。 Pod的设计理念是 每个Pod都有一个唯一的IP。
Pod具有如下特征：
容器生命周期钩子函数，用于监听容器生命周期的特定事件，并在事件发生时执行已注册的回调函数，支持两种钩子函数：postStart和preStop，前者是在容器启动后执行，后者是在容器停止前执行
Namespace（命名空间）是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或者用户组。常见的pod、service、replicaSet和deployment等都是属于某一个namespace的(默认是default)，而node, persistentVolumes等则不属于任何namespace。
常用namespace操作：
# 查询所有namespaces kubectl get namespace # 创建namespace kubectl create namespace ns-name # 删除namespace kubectl delete namespace ns-name
删除命名空间时，需注意以下几点：
Events是否属于namespace取决于产生events的对象。
Node是Pod真正运行的主机，可以是物理机也可以是虚拟机。Node本质上不是Kubernetes来创建的， Kubernetes只是管理Node上的资源。为了管理Pod，每个Node节点上至少需要运行container runtime（Docker）、kubelet和kube-proxy服务。
常用node操作：
# 查询所有node kubectl get nodes # 将node标志为不可调度 kubectl cordon $nodename # 将node标志为可调度 kubectl uncordon $nodename
taint(污点)
使用kubectl taint命令可以给某个Node节点设置污点，Node被设置上污点之后就和Pod之间存在了一种相斥的关系，可以让Node拒绝Pod的调度执行，甚至将Node已经存在的Pod驱逐出去。每个污点的组成：
key=value:effect，当前taint effect支持如下三个选项：
常用命令如下：
# 为节点node0设置不可调度污点 kubectl taint node node0 key1=value1:NoShedule # 将node0上key值为key1的污点移除 kubectl taint node node0 key- # 为kube-master节点设置不可调度污点 kubectl taint node node1 node-role.kubernetes.io/master=:NoSchedule # 为kube-master节点设置尽量不可调度污点 kubectl taint node node1 node-role.kubernetes.io/master=PreferNoSchedule
容忍(Tolerations)
设置了污点的Node将根据taint的effect：NoSchedule、PreferNoSchedule、NoExecute和Pod之间产生互斥的关系，Pod将在一定程度上不会被调度到Node上。 但我们可以在Pod上设置容忍(Toleration)，意思是设置了容忍的Pod将可以容忍污点的存在，可以被调度到存在污点的Node上。
Service是对一组提供相同功能的Pods的抽象，并为他们提供一个统一的入口，借助 Service 应用可以方便的实现服务发现与负载均衡，并实现应用的零宕机升级。 Service通过标签(label)来选取后端Pod，一般配合ReplicaSet或者Deployment来保证后端容器的正常运行。
service 有如下四种类型，默认是ClusterIP：
NodeIP:NodePort 来访问该服务另外，也可以将已有的服务以Service的形式加入到Kubernetes集群中来，只需要在创建 Service 的时候不指定Label selector，而是在Service创建好后手动为其添加endpoint。
默认情况下容器的数据是非持久化的，容器消亡以后数据也会跟着丢失，所以Docker提供了Volume机制以便将数据持久化存储。Kubernetes提供了更强大的Volume机制和插件，解决了容器数据持久化以及容器间共享数据的问题。
Kubernetes存储卷的生命周期与Pod绑定
目前Kubernetes主要支持以下Volume类型：
...
PersistentVolume(PV)是集群之中的一块网络存储。跟 Node 一样，也是集群的资源。PersistentVolume (PV)和PersistentVolumeClaim (PVC)提供了方便的持久化卷: PV提供网络存储资源，而PVC请求存储资源并将其挂载到Pod中。
PV的访问模式(accessModes)有三种:
不是每一种存储都支持这三种方式，像共享方式，目前支持的还比较少，比较常用的是 NFS。在PVC绑定PV时通常根据两个条件来绑定，一个是存储的大小，另一个就是 访问模式。
PV的回收策略(persistentVolumeReclaimPolicy)也有三种
Delete，删除存储资源
一般情况下我们不需要手动创建Pod实例，而是采用更高一层的抽象或定义来管理Pod，针对无状态类型的应用，Kubernetes使用Deloyment的Controller对象与之对应。其典型的应用场景包括：
常用的操作命令如下：
# 生成一个Deployment对象 kubectl run www --image=10.0.0.183:5000/hanker/www:0.0.1 --port=8080 # 查找Deployment kubectl get deployment --all-namespaces # 查看某个Deployment kubectl describe deployment www # 编辑Deployment定义 kubectl edit deployment www # 删除某Deployment kubectl delete deployment www # 扩缩容操作，即修改Deployment下的Pod实例个数 kubectl scale deployment/www --replicas=2 # 更新镜像 kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 # 回滚操作 kubectl rollout undo deployment/nginx-deployment # 查看回滚进度 kubectl rollout status deployment/nginx-deployment # 启用水平伸缩（HPA - horizontal pod autoscaling），设置最小、大实例数量以及目标cpu使用率 kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80 # 暂停更新Deployment kubectl rollout pause deployment/nginx-deployment # 恢复更新Deployment kubectl rollout resume deploy nginx
更新策略
.spec.strategy 指新的Pod替换旧的Pod的策略，有以下两种类型
RollingUpdate 滚动升级，可以保证应用在升级期间，对外正常提供服务。Recreate 重建策略，在创建出新的Pod之前会先杀掉所有已存在的Pod。Deployment和ReplicaSet两者之间的关系
当执行更新操作时，会创建一个新的ReplicaSet，Deployment会按照控制的速率将pod从旧的ReplicaSet移 动到新的ReplicaSet中
Deployments和ReplicaSets是为无状态服务设计的，那么StatefulSet则是为了有状态服务而设计，其应用场景包括：
支持两种更新策略：
.spec.template更新时，并不立即删除旧的Pod，而是等待用户手动删除这些旧Pod后自动创建新Pod。这是默认的更新策略，兼容v1.6版本的行为.spec.template 更新时，自动删除旧的Pod并创建新Pod替换。在更新时这些Pod是按逆序的方式进行，依次删除、创建并等待Pod变成Ready状态才进行下一个Pod的更新。9 DaemonSet 守护进程集
DaemonSet保证在特定或所有Node节点上都运行一个Pod实例，常用来部署一些集群的日志采集、监控或者其他系统管理应用。典型的应用包括:
指定Node节点
目前支持两种策略*
RollingUpdate: 更新DaemonSet模版后，自动删除旧的Pod并创建新的Pod
Kubernetes中的负载均衡我们主要用到了以下两种机制：
Service和Pod的IP仅可在集群内部访问。集群外部的请求需要通过负载均衡转发到service所在节点暴露的端口上，然后再由kube-proxy通过边缘路由器将其转发到相关的Pod，Ingress可以给service提供集群外部访问的URL、负载均衡、HTTP路由等，为了配置这些Ingress规则，集群管理员需要部署一个Ingress Controller，它监听Ingress和service的变化，并根据规则配置负载均衡并提供访问入口。
常用的ingress controller：
Openresty
Job负责批量处理短暂的一次性任务 (short lived one-off tasks)，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束。
CronJob即定时任务，就类似于Linux系统的crontab，在指定的时间周期运行指定的任务。
Horizontal Pod Autoscaling可以根据CPU、内存使用率或应用自定义metrics自动扩展Pod数量 (支持replication controller、deployment和replica set)。
支持三种metrics类型
可以通过如下命令创建HPA：
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
Service account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的
授权
Service Account为服务提供了一种方便的认证机制，但它不关心授权的问题。可以配合RBAC(Role Based Access Control)来为Service Account鉴权，通过定义Role、RoleBinding、ClusterRole、ClusterRoleBinding来对sa进行授权。
Sercert-密钥解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者Pod Spec中。Secret可以以Volume或者环境变量的方式使用。有如下三种类型：
Service Account:用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的 /run/secrets/kubernetes.io/serviceaccount 目录中;
Opaque:base64编码格式的Secret，用来存储密码、密钥等;
kubernetes.io/dockerconfigjson: 用来存储私有docker registry的认证信息。
ConfigMap用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。ConfigMap跟secret很类似，但它可以更方便地处理不包含敏感信息的字符串。ConfigMap可以通过三种方式在Pod中使用，三种分别方式为:设置环境变量、设置容器命令行参数以及在Volume中直接挂载文件或目录。
可以使用 kubectl create configmap从文件、目录或者key-value字符串创建等创建 ConfigMap。也可以通过 kubectl create -f value.yaml 创建。
资源配额(Resource Quotas)是用来限制用户资源用量的一种机制。
资源配额有如下类型：
计算资源，包括cpu和memory
存储资源，包括存储资源的总量以及指定storage class的总量
对象数，即可创建的对象的个数
它的工作原理为:
用户超额后禁止创建新的资源
