部署形态
IaaS层的价值在于资源的编排（调度），那么K8S就必须要重新实现资源管理相关的功能，比如裸机（包括纯物理机）管理、虚拟机的管理（必然还会存在），存储的管理（集中式存储、各种分布式存储等），网络的管理（各种SDN的对接或者功能实现，underlay和overlay网络），安全组件的管理（安全设备、安全虚拟化设备）等等，除非你认为在以应用编排为主体的时代，不需要资源管理，很显然，这都是不对的，K8S的重点应该围绕应用和服务，而不是过多关注底层硬件资源的管理。penStack必然要交出整个平台的控制权，交给以应用为中心的K8S，但是，不以你为中心，并不代表不需要OpenStack，更不存在K8S替代OpenStack。VMWare是这个理念的先行者，推出了虚拟机和容器深度结合的项目Project Pacific，在这个项目中并没有用K8S替代vCenter、vSAN等，只是把控制权从vCenter转交给了K8S。
方案一：K8S部署在OpenStack上
K8S部署在OpenStack平台上，OpenStack Magnum项目的方案实现的代表，该项目为Openstack提供了容器编排服务，通过该组件完成K8S集群搭建，原理和OpenStack组件实现差不多，通过Heat完成资源编排（创建虚拟机、volume、安全组等），然后通过镜像里面的heat-container-agent以及一些脚本完成K8S的安装配置。支持通过Ironic，Magnum支持将容器编排组件直接部署在物理机（裸机）上。
由 OpenStack 社区开发，这是 OpenStack 官方的 Kubernetes 等 COE（Container Orchestration Engine）部署和管理解决方案。
部署形态：
基于K8S有插件式的二次开发的话在进行深度开发，在维护和升级上会有难度。
方案二：K8S和OpenStack组件集成部署
K8S与OpenStack Keystone集成；
K8S与OpenStack Glance集成；docker使用Registry或者Harbor 可以使用glance存储Docker镜像作为备份。
K8S与OpenStack Neutron集成：K8S直接OpenStack Neutron集成，即kuryr-kubernetes项目。K8S的pod与Openstack虚拟机时平等的，共享网络服务（安全组，防火墙，Qos等）
K8S与Cinder集成；目前K8S已经实现了很多volume插件，PC支持对接各种存储系统，比如Ceph RBD、GlusterFS、NFS等等，参考kubernetes persistent volumes，其中就包含了Cinder，即K8S可以使用cinder提供volume服务，这样K8S和Nova共享一套存储系统，都是cinder的消费者。
https://github.com/kubernetes/cloud-provider-openstack
https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-openstack-cloud-controller-manager.md
参考K8S集成keystone部署https://www.xiayinchang.top/post/699b195d.html
参考K8S集成Neutron部署https://blog.csdn.net/ptmozhu/article/details/70159727
参考K8S集成Cinder部署https://www.jianshu.com/p/87b02040991c
方案三：K8S部署在物理机
K8S集群直接部署在物理机上，单独部署。
部署方式通过自动化部署工具kubespray部署工具进行部署；部署详细信息
高可用部署
K8S 核心组件如下表；
ETCD 1：基本的key-value存储
2：监听机制
3：key的过期及续约机制，用于监控和服务发现
4：原子CAS和CAD，用于分布式锁和leader选举
kube-apiserver 1：提供集群管理的REST API接口，包括认证授权/数据校验以及集群状态变更等；
2：提供其他模块之间数据交互和通信的枢纽
kube-scheduler 负责分配调度Pod到集群内的节点上，它监听Kube-apiserver，查询还未分配Node的Pod，然后根据调度策略为这些Pod分配节点；
Controller Manager Controller Manager由kube-controller-manager和cloud-controller-manager组成，是Kubernetes的大脑，它通过apiserver监控整个集群的状态，并确保集群处于预期的工作状态。
Kubelet 每个Node节点上都运行一个Kubelet服务进程，默认监听10250端口，接收并执行Master发来的指令，管理Pod及Pod中的容器，每个kubelet进程会在API Server上注册所在Node节点的信息，定期向Master节点汇报该节点的资源使用情况，并通过cAdvisor监控节点和容器的资源。
kube-proxy 监听API server中service和endpoint的变化情况，并通过iptables等来为服务配置负载均衡。
kube-dns DNS通过kube-dns或CoreDNS作为集群的必备扩展来听过命名服务。
kubectl 为Kubernetes的命令行工具，是Kubernetes用户和管理员必备的管理工具。
Kubernetes作为容器应用的管理平台，通过对Pod的运行状况进行监控，并且根据主机或容器失效的状态将新的Pod调度到其他Node上，实现了应用层的高可用性。
在Kubernetes系统中，Master服务扮演着总控中心的角色，主要的 三个服务kube-apiserver、kube-controller-mansger和kube-scheduler通过不 断与工作节点上的kubelet和kube-proxy进行通信来维护整个集群的健康 工作状态。如果Master的服务无法访问某个Node，则会将该Node标记为不可用，不再向其调度新建的Pod。但对Master自身则需要进行额外监控，使Master不成为集群的单故障点，所以对Master服务也需要进行高 可用部署。
以Master的kube-apiserver、kube-controller-mansger和kube-scheduler三个服务作为一个部署单元，类似于etcd集群的典型部署配置。使用至少三台服务器安装Master服务，并且需要保证任何时候总有一套Master能够正常工作。
高可用系统包括：
1：Etcd集群模式
2：kube-apiserver负载均衡
3：kube-controller-manager、kube-scheduler 和 cluster-autoscaler 自动选主（有且仅有一个运行实例）
高可用集群搭建流程
ETCD集群
etcd在整个Kubernetes集群中处于中心数据库的地位，为保证 Kubernetes集群的高可用性，首先需要保证数据库不是单一故障点。一方面，etcd需要以集群的方式进行部署，以实现etcd数据存储的冗余备份与高可用；另一方面，etcd存储的数据本身也应考虑使用可靠的存储设备。
etcd集群的部署可以使用静态配置，也可以通过etcd提供的RESTAPI在运行时动态添加、修改或删除集群中的成员。本节将对etcd集群的静态配置进行说明。关于动态修改的操作方法请参考etcd官方文档的说明。
Kube-apiserver部署
把 kube-apiserver.yaml 放到每台 Master 节点的 /etc/kubernetes/manifests/ ，并把相关的配置放到 /srv/kubernetes/ ，即可由 kubelet 自动创建并启动 apiserver:
kube-apiserver 启动后，还需要为它们做负载均衡，可以使用云平台的弹性负载均衡服务或者使用 haproxy/lvs 等为 master 节点配置负载均衡。
Kube-controller-manager和kube-scheduler
kube-controller manager 和 kube-scheduler 需要保证任何时刻都只有一个实例运行，需
要一个选主的过程，所以在启动时要设置 --leader-elect=true，把 kube-scheduler.yaml 和 kube-controller-manager.yaml 放到每台 master节点的 /etc/kubernetes/manifests/ 即可
kube-dns
kube-dns 可以通过 Deployment 的方式来部署，默认 kubeadm 会自动创建。但在大规
模集群的时候，需要放宽资源限制
Kube-proxy
默认kube-proxy使用iptables来为Service作负载均衡，这在大规模时会产生很大的延迟，可以考虑使用IPVS的替代方式。
另外，需要注意配置kube-proxy使用kube-apiserver负载均衡的IP地址；
Kubelet
Kubelet需要配置kube-apiserver负载均衡的IP地址
数据持久化
对于物理机部署的集群，可以考虑使用iSCSI NFS Cluster或者Ceph等网络存储，也可以使用RAID