建议：在生产场景中，最好一开始部署集群时将使用哪种网络规划好，后期再更换的话，运行中的pod会全部更换网络，甚至ip都会发生变化，会对环境产生一定的影响。更换之前在测试环境先测试一遍它对pod的影响。
在公司kubernetes项目部署中，脚本运行了大量的pod，其中包括环境中必不可少的监控，而对于kubernetes来说，最适合的监控莫过于Prometheus了，再通过grafana去展示监控图表。
Secret 可以为 Pod 提供密码、Token、私钥等敏感数据；对于一些非敏感数据，比如应用的配置信息，则可以用 ConfigMap。
ConfigMap 的创建和使用方式与 Secret 非常类似，主要的不同是数据以明文的形式存放。
应用启动过程中可能需要一些敏感信息，比如访问数据库的用户名密码或者秘钥。将这些信息直接保存在容器镜像中显然不妥，Kubernetes 提供的解决方案是 Secret。
Secret 会以密文的方式存储数据，避免了直接在配置文件中保存敏感信息。Secret 会以 Volume 的形式被 mount 到 Pod，容器可通过文件的方式使用 Secret 中的敏感数据；此外，容器也可以环境变量的方式使用这些数据。
这里使用nfs为PV&PVC做后端存储
[root@node1 ~]# yum -y install nfs-utils rpcbind
[root@node1 ~]# mkdir /nfsdata/mysql_pv
[root@node1 ~]# vim /etc/exports
/nfsdata *(rw,no_root_squash,sync)
[root@node1 ~]# exportfs -r
[root@node1 ~]# systemctl start rpcbind nfs-server
[root@node1 ~]# systemctl enable rpcbind nfs-server与Docker中一样，同样是通过Volume来管理存储资源，Kubernetes的Volume比Docker的类型多，支持的存储也多，如：nfs、fastdfs、iscsi等
试想一个场景
现在有一个正常运行的多副本应用，要对应用进行更新（比如更新image），Kubernetes会启动新副本来代理旧副本，然后发生了以下事件：
1、正常情况下新副本需要10s左右来完成准备工作，在此之前无法响应更新后的业务请求。
2、但由于人为配置错误，副本始终无法完成准备工作（比如无法连接后端数据库）
强大的自愈能力是 Kubernetes 这类容器编排引擎的一个重要特性。自愈的默认实现方式是自动重启发生故障的容器。除此之外，用户还可以利用 Liveness 和 Readiness 探测机制设置更精细的健康检查，进而实现如下需求：
在docker swarm中可以使用命令检查服务是否健全（探测某个目录或者某个文件），来判断是否可以提供正常的服务。
当想要更新启动的pod镜像时，可以通过滚动更新，不停止Pod的情况下，将版本更新完成，非常简单 滚动更新是一次只更新一小部分副本，成功后，再更新更多的副本，最终完成所有副本的更新。滚动更新的最大的好处是零停机，整个更新过程始终有副本在运行，从而保证了业务的连续性。
Kubernetes中的Pod是很容易因为各种原因发生故障而死掉。Deployment等Controller会通过动态创建和销毁Pod来保证应用整体的健壮性。换句话说，Pod是脆弱的，但应用是健壮的。
每个Pod都有自己的IP地址。当Controller用新的Pod替代发生故障的Pod时，新Pod会分配到新的IP地址。这样就会产生一个问题：访问的地址也会发生变化，怎么保证在替换Pod后依然可以访问这个服务。
在docker run和swarm中使用-p来映射端口来解决这一问题，而Kubernetes给出的解决方案是Service，这里的Service与swarm中的Service是不一样的。同样它的解决方案也是映射端口的原理。
容器安装持续运行的时间可分为两类：服务类容器和工作类容器
服务类容器通常持续提供服务，需要一直运行，比如web server，daemon等。工作类容器则是一次性任务，比如批处理程序，完成后容器就退出。
Kubernetes的Deployment、ReplicaSet和DaemonSet都用于管理服务类容器；对于工作类容器，就可以使用Job
在前面介绍组件的时候说过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 来建立副本管理机制。