部门产品线本身是做DEVOPS平台，最近部署架构也在往K8S上靠了，不得不学一下K8S。自己搭建了K8S集群与harbor仓库来学习。
1、kubernetes之常用核心资源对象
1.1、K8s服务部署
Kubernetes: 用来编排（管理）容器的，但是kubernetes不直接部署容器，而是通过部署一个pod服务来间接管理容器，pod内部封装的是一个容器。
1.2、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 1.3、标签label
标签定义：标签用于区分对象（比如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服务被当前的副本控制器控制？
答案： 通过标签确定哪些服务属于谁控制；
1.4、volume
Volume是kubernetes抽象出来的数据存储资源对象；和docker的volume没有关系，volume数据卷会把存储介质（磁盘，网络文件系统）中数据挂载到pod服务内容的容器中，volume是k8s管理的数据卷；
小结：
1、volume数据卷本身并不存储数据，只是把数据给挂载到pod服务内部的容器中去，volume仅仅是k8s管理的资源对象
2、pod内部服务容器宕机了，volume数据卷不会丢失。
3、pod服务宕机，消失了。Volume数据卷也会消失，且数据全部丢失。
1.5、副本控制器
副本控制器资源对象名称： 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资源对象，实现服务滚动更新，扩容缩容。
1.6、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 
1.7、DaemonSet
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/
