之前做过使用docker来启动registry私库，在使用了Kubernetes之后，容器的形式都变成了Pod，也不会去想只有一个registry还是去使用docker来去启动，所以本文是作者本人自己去写的一些内容来做的registry以及验证。版权纯属于本博主
如果已经装过的kube-ovn想要去更换网络插件或者重新部署一遍拆件，可以使用此方法
官方给出了卸载kube-ovn的clean脚本，下载执行即可
安装环境
不支持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 |
建议：在生产场景中，最好一开始部署集群时将使用哪种网络规划好，后期再更换的话，运行中的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