在前面介绍组件的时候说过DaemonSet，和swarm集群的global模式是一样的，每个Node最多只能运行一个副本。
DaemonSet的典型的应用场景
1、在集群的每个节点上运行存储Deamon，比如glusterd或ceph
2、在每个节点上运行日志收集Daemon，比如flunentd或logstash
3、在每个节点上运行监控Daemon，比如Prometheus Node Export或collectd
默认配置下，Scheduler 会将 Pod 调度到所有可用的 Node。不过有些情况我们希望将 Pod 部署到指定的 Node，比如将有大量磁盘 I/O 的 Pod 部署到配置了 SSD 的 Node；或者 Pod 需要 GPU，需要运行在配置了 GPU 的节点上。
Kubernetes是通过label来实现这个功能的，同之前的docker swarm集群的label是一样的，通过对节点进行label的设置，将Pod运行的指定的label节点上。
ReplicationController确保在任何时候都有特定数量的Pod副本处于运行状态，也叫作期望值，换句话说，ReplicationController确保一个Pod或一组同类的Pod总是可用的。ReplicationController的功能已经被ReplicaSet接管
现在推荐使用配置 ReplicaSet 的 Deployment 来建立副本管理机制。
标题中所说的Scale Up or Down也就是伸缩，Deployment的伸缩也是主要对pod的伸缩，达到高可用以及负载的目的。
这个环境是生产环境中的真实项目，仅做参考 通过Docker+k8s来部署web集群，GitLab+Jenkins实现代码自动化部署，在Jenkins中通过构建脚本，实现k8s对容器web集群代码自动更新
上篇文档中了解到新版本1.18的Kubernetes不能使用kubectl run的--replicas，这篇文章中将会使用另一种方法来创建K8S资源deployment
在k8s部署之前，回忆以下之前说过的Deployment，可以创建应用程序（docker image）的实例（docker container），这个实例被包含在称为Pod的概念中，Pod是k8s最小的可管理单元。 在k8s集群中发布Deployment后，它将指示k8s如何创建和更新应用程序实例，master节点的Scheduler将应用程序实例调度到集群中的具体节点上。 之后Deployment会持续监控这些实例。一旦实例所在节点发生故障，会在其他节点重新创建一个新的实例。
k8s在市面上的大火，导致不得不去学习它，去适应公司的需求。
Kubernetes是一个基于docker对容器进行编排的引擎，包括了安装部署、应用管理、网络、存储、监控、日志管理等多个方面。
安装环境
不支持centos8的系统（现在已经支持了）
| ip | 服务 | 硬件要求 |
|---|---|---|
| 192.168.1.11（node1） | Docker（已安装）、kubernetes | 内存4G，双核CPU |
| 192.168.1.12（node2） | Docker（已安装）、kubernetes | 内存4G，双核CPU |
| 192.168.1.13（node3） | Docker（已安装）、kubernetes | 内存4G，双核CPU |
4 / 4
