部署形態
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