部门产品线本身是做DEVOPS平台，最近部署架构也在往K8S上靠了，不得不学一下K8S。自己搭建了K8S集群与harbor仓库来学习。
1、kubernetes之常用核心资源对象 1.1、K8s服务部署Kubernetes: 用来编排（管理）容器的，但是kubernetes不直接部署容器，而是通过部署一个pod服务来间接管理容器，pod内部封装的是一个容器。
POD是kubernetes集群的最小任务调度单元。
Kubernetes里的所有资源对象都可以采用YAML或者JSON格式的文件来定义描述。比如下面的POD定义：
apiVersion: v1
kind: Pod
metadata:
name: mytomcat
labels:
name: mytomcat
spec:
containers:
- name: mytomcat
image: harbor.hyz.com/library/mytomcat:v1
prots:
- containerPort: 8080
标签定义：标签用于区分对象（比如Pod、Service），键/值对存在；每个资源对象可以有多个标签，通过标签关联对象。
Kubernetes中任意API对象都是通过Label进行标识，Label的实质是一系列的Key/Value键值对，其中key于value由用户自己指定。
Label可以附加在各种资源对象上，如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去。
Label是Replication Controller和Service运行的基础，二者通过Label来进行关联Node上运行的Pod。
我们可以通过给指定的资源对象捆绑一个或者多个不同的Label来实现多维度的资源分组管理功能，以便于灵活、方便的进行资源分配、调度、配置等管理工作。
一些常用的Label如下：
版本标签："release":"stable","release":"canary"......
环境标签："environment":"dev","environment":"qa","environment":"production"
架构标签："tier":"frontend","tier":"backend","tier":"middleware"
分区标签："partition":"customerA","partition":"customerB"
质量管控标签："track":"daily","track":"weekly"
问题： 在服务器部署的容器云环境中，有成千上万个POD服务，那么副本控制器是如何知道哪些pod服务被当前的副本控制器控制？
答案： 通过标签确定哪些服务属于谁控制；
Volume是kubernetes抽象出来的数据存储资源对象；和docker的volume没有关系，volume数据卷会把存储介质（磁盘，网络文件系统）中数据挂载到pod服务内容的容器中，volume是k8s管理的数据卷；
小结：
1、volume数据卷本身并不存储数据，只是把数据给挂载到pod服务内部的容器中去，volume仅仅是k8s管理的资源对象
2、pod内部服务容器宕机了，volume数据卷不会丢失。
3、pod服务宕机，消失了。Volume数据卷也会消失，且数据全部丢失。
副本控制器资源对象名称： ReplicationController(淘汰，只支持单个标签选择器), ReplicaSet（目前使用这款副本控制器，支持符合标签选择器）
作用：用来保证服务副本数量与预期所设定的数量保持一致，也就是说服务永远保证服务处于高可用状态。
场景：当服务上线部署后，一段时间后某一个服务（POD）宕机了，副本控制器立马对服务进行重建，永远保证服务数量等于之前所设定数量（例如： 规定服务集群服务数量=3，副本控制将会永远保证服务数量为3）；
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: frontend
spec:
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
tier: frontend
spec:
containers:
- name: tomcat-demo
image: harbor.hyz.com/library/mytomcat:v1
imagePullPolicy: IfNotPresent
env:
- name: GET_HOST_FROM
value: dns
ports:
- containerPort: 80
问题1： ReplicaSet副本控制器仅仅是控制POD副本数量（仅仅是一个副本控制器），不支持滚动更新，扩容缩容等；因此必须引入Deployment资源对象，实现服务滚动更新，扩容缩容。
Deployment为Pod和ReplicaSet 提供了一个 声明式定义方法，相当于RC/RS的升级版。其中一个最大升级功能是我们可以随时知道当前pod“部署”的进度。
典型的应用场景：
（1）、定义Deployment 来创建 Pod 和 ReplicaSet
（2）、滚动升级和回滚应用
（3）、扩容和索容
（4）、暂停和继续 Deployment
Deployment不仅仅可以滚动更新，而且可以进行回滚，如果发现升级到V2版本后，发现服务不可用，可以回滚到V1版本。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
DaemonSet确保全部（或者一些 [ node打上污点（可以想象成一个标签）,pod如果不定义容忍这个污点，那么pod就不会被调度器分配到这个node ]）Node上运行一个Pod的副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除他创建的所有Pod,使用DaemonSet 的一些典型用法：
（1）在每个Node上运行日志收集Daemon,例如：fluentd、logstash.
（2）在每个Node上运行监控Daemon,例如：Prometheus Node Exporter
小结： DeamonSet控制器，让每一个node节点都部署一个相同服务（副本），因此deamonSet通常被用来部署一些公共的服务。
这些公共服务，每一个节点都需要；
例如：
需求： 在服务集群网络中，收集每一个节点的日志（每一个节点都需要部署一个收集日志程序）
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: daemonset-logstash
namespace: default
labels:
k8s: logstash
spec:
selector:
matchLabels:
name: daemonset-logstash
template:
metadata:
labels:
name: daemonset-logstash
spec:
tolerations:
# 这些容忍度设置是为了让守护进程在控制平面节点上运行
# 如果你不希望控制平面节点运行 Pod，可以删除它们
- key: node-role.kubernetes.io/control-plane
operator: Exists
effect: NoSchedule
containers:
- name: logstash
image: logstash
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
参考：https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/daemonset/