-
Kubernetes架構全圖
查看全部 -
7-1回顧總結
介紹部署模式變遷，體驗k8s集群
介紹k8s架構：maset,nodes
介紹k8s對象，具體介紹了pod和控制器；configMap和secret
查看全部 -
6-4? 常用的工作負載類、配置和存儲類對象講解
Pod的生命周期
phase:是Pod生命周期所處位置的概括，從phase的值可以反映Pod生命周期形態
Pending:掛起，創建,部署階段,pod已經被k8s集群接受，但有一個或多個容器鏡像尚未創建，即Pending階段是通過網絡下載容器鏡像，調度Pod等 等待時間
Running Pod已經綁定到一個節點上，Pod中所有容器已經被創建，并且至少有一個容器正在啟動或運行或重啟
Succeed 此時Pod所有容器被成功終止，并且不會再重啟
Failed Pod容器都已經被終止了，并且至少有一個容器因失敗而終止，即容器以非0狀態退出導致系統終止的
（被廢除的unknown:以未知原因無法取得Pod狀態）
---
Service：服務發現，負載均衡Load balance的核心對象
前言：Pod是一個非持久性的實體對象，通常會由各種原因被終止，每次重啟ip地址都會改變，所以Pod的ip地址是不能被穩定依賴的；問題來了，pod的ip地址不可靠前提下，我們怎么發現并連接到Pod呢，于是有了Service抽象概念。
Service：與云原生應用的“微服務”概念一一對應
????k8s為每個Service分配一個集群唯一的IP地址，在Service生命周期內，ip地址不變；在內部DNS支持下，能輕松實現服務發現機制。
????Service通過label seletor關聯到實際支撐業務的pod上，并通過集群內置的服務負載均衡將服務請求分發到后端Pod；即調用者無需關心pod狀態如何，是否創建，pod的ip是否發生了變化。
????通過nodeport或者設置load balancer（負載均衡？）還可以實現將service暴露到集群外部。
k8s還支持多重昂service，比如沒有seletor的service，比如不需要分配ip不需要負載均衡的service（高級話題）
---
Controllers：與Pod關聯最為緊密的控制器對象，控制器對象就是為Pod保駕護航的。
????各種控制器就是為了保證一組Pod始終保證處于期望狀態（desired state）正常運行。期望狀態包括：Pod副本數量，節點選擇，資源約束，持久化數據維持等...
????常用的控制器：deployment、replicaset、statefulset、daemonset等
????????replicaset：副本集合控制器，確保健康Pod數量始終滿足用戶定義的數量。
????????????它的前身是ReplicationController(rc),新版RS支持集合式的label selector標簽篩選（等優勢？）
????????????雖然想Pod一樣可以手動創建，但官方推薦使用deployment創建并由其自動管理replicaset，這樣就可以不用擔心兼容問題，比如repllicaset不支持滾動更新，但deployment支持。
????????deployment:是k8s最常用的控制器，它為Pod和ReplicaSet提供了聲明式定義（yaml）。聲明式的意思是，描述他們狀態是怎么樣的，而不是說描述他們的創建步驟和方法。
????????????用戶在deployment描述Pod和ReplicaSet的期望狀態，DeploymentControlller就會自動將他們改變到期望（不要嘗試手動修改由deployment自動創建的ReplicaSet,否則可能會引發未知后果）
????????????周所周知，Deployment支持Pod的滾動更新，并自動管理背后的ReplicaSet,例如更新Pod模板、規格字段來升級Pod新狀態時，Deployment會自動創建新的ReplicaSet,Deployment會根據控制速率將Pod舊的ReplicaSet移動到新的那里。以實現ReplicaSet的滾動更新。
????????? ? Deployment支持Pod回滾，但僅由pod模板（Pod-template）改動的行為觸發的版本升級。
---
StatefulSet:Deployment,ReplicaSet等控制器,他們僅用于無狀態應用的部署和管理，對于有狀態應用，v1.5后k8s提供了StatefulSet提供支持
v1.9畢業，說明可以在環境中可以正常使用了。保證了產品的先后兼容。
為了解決有狀態服務的部署問題，例如需要
穩定的的持久化存儲，集合的Pod被重新調度后，還是能訪問到相同的持久化存儲的。
穩定的網絡表示；Pod重新調度后，即PodName等標簽不變，
有序部署擴展：Pod是有順序的，Pod在部署或擴展的時候，要根據定義的順序依次進行，
有序收縮，刪除：Pod在被刪除收縮等過程中，也要根據定義的順序依次進行，
有序自動滾動升級等：和有序收縮一樣，依據定義的順序依次進行，每次升級一個Pod，只有一個Pod完成升級才會進行下一個。
Pod的存儲必須由RersistentVolume Provisioner根據請求的Storage Class進行配置，或由管理員預先配置好。
考慮到數據安全性，伸縮或刪除StatefulSet不會刪除關聯的存儲；另外StatefulSet要求沒有class ip的Headless Service負責Pod的網絡身份，用戶有責任創建此類服務。（高級話題）
---
DaemonSet:特殊的控制器，保證在每個Node上都運行一個Pod副本，當增加/溢出Node，會自動增加/收回Pod副本，刪除DaemonSet會刪除它創建的所有Pod
????適用于：系統Daemon程序sifvillike組件，監控跟蹤clkD，日志收集runD等
????1.6以后支持滾動更新
? ? 支持通過nodeSelector、nodeAffinity、podAffinity來選擇需要部署的Node，當Node的標簽發生變化時，DaemonSet會重新匹配Node，并在新匹配的Node上部署Pod副本并將原有的但此次為匹配到的Node的Pod副本刪除。
---配置和存儲類對象
ConfigMap：允許我們將配置信息與容器鏡像內容解耦，這樣可以保持容器化應用鏡像的可移植性，沒有必要因為配置的變動而重新制作容器鏡像，常用來想Pod提供非敏感的配置信息。
????configMap用于保存配置數據的鍵值對，可用來保存單個屬性、配置文件
????configMap可以用命令行基于字面值，文件或目錄來創建或通過configMap對象定義文件yaml創建。
????configMap可以通過三種方式在Pod中使用：環境變量，容器命令行或以文件形式通過數據卷插件掛在到Pod中。
示例：configMap的常見和使用
定義kind:configMap的yaml，里面定義屬性配置data.title,data.authtor
定義一個kind:Pod的yaml,并將之前的配置信息以環境變量的形式使用
啟動pod，查看輸出
---
Secret使用上與ConfigMap類似，不同的是它解決是集群內密碼，token,密鑰等敏感數據的配置問題
????應用場景：鯧魚ServiceAccount關聯，存儲在tmpfs系統，Pod刪除后Secret文件也會對應地刪除。
????有三種Secret:
Opaque:64編碼格式的secret,存儲密碼密鑰，
Service Account：在pod中訪問k8s api服務的，有k8s自動創建。并掛載在到Pod指定目錄中去，
dockerconfigjson：用來存儲私有docker鏡像倉庫的認證信息，
????secret可以以volume或環境變量方式使用。
查看全部 -
6-3 k8s對象分類
工作負載類，k8s主要去管理和運營的對象。
發現和負載均衡類：與服務相關的類對象。
配置和存儲類：向應用中注入初始化配置數據，或將數據持久化保存到容器外的對象
集群類cluster：定義了集群自身該如何配置的數據，通常由集群管理員進行操作。
---
工作負載：核心工作負載對象Pod，其他對象都是為Pod提供功能服務的。
controller控制器用于維護Pod狀態，配置和存儲對象為Pod注入了初始化數據，并持久化Pod運行時產生的數據；
Service將Pod聚合在一起，統一為集群內外提供服務。
Pod：集群調度基本單元。有特定關系的容器集合，比容器更高級別的抽象。是k8s中可以創建，部署的最小對象單元。
????一個Pod就代表了集群運行的一個進程
????一個Pod也是一種封裝。應用容器，存儲資源，獨立網絡IP和決定容器如何運行的策略選項。
????每個Pod內置一個Pause容器，它的名字空間，IPC自選，網絡和存儲資源被Pod內其他容器共享，是Pod實現容器資源共享的基礎。Pod中的容器可以通過localhost相互訪問，Pod作為一個整體被管理。
Pod生命周期：
?????Pod是一個非持久性實體，節點故障，缺少資源等情況下Pod可能會被驅逐出存在節點，所以不建議手動創建Pod，而是用控制器創建，自動管理Pod，更加方便，而且自動管理還包括控制器對Pod的自動伸縮。
查看全部 -
6-2 Metadata
k8s對象中Metadata是最常見的靜態屬性
????Name和UID：所有對象都由Name和UID明確標識。
????????同一類的對象中，Name唯一；
????????不同類的對象中，Name可以一樣；
????????不同名字空間在，Name可以一樣；
????????某個Pod叫“Hello k8s”，某個deployment也可以叫“Hello k8s”
????????每個對象部署后，有一個唯一標識UID，該UID在k8s集群整個生命周期范圍內都是唯一的，為了與歷史部署過的同名對象做區分。
????????API可以通過對象名字訪問，通用路徑：/api/{version}/namespaces/{namespace}/{object-kind}/name
如：/api/v1/namespaces/default/pods/hello-k8s
????Namespace：不僅是一個屬性，本身還是一個object
????????提供獨立的命名空間，將物理集群劃分為多個虛擬集群，對象的名稱（spec.name）在同一個名字空間內是唯一的
????????namspace間互相獨立，所以常用來隔離不同的用戶和權限
????????k8s有三個內置的namespace,
????????????default:默認的
????????????kube-system:平臺組件部署的，api server,dns插件,網關插件等
????????????kube-public:自動創建，供所有用戶訪問，包括未經過身份驗證的用戶訪問，它主要還是為集群自用創建的，以便資源在集群中公開可見可讀。
????????????Node,PersistentVolume不屬于任何namespace。
????Label：k8s原對象都有的元數據屬性，用于建立集群對象之間松耦合的關聯關系。
????????一個Label就是第一個鍵值對。只要符合標簽語法規定即可
????????label可以附著在任何對象上，任何對象都可以有任意標簽；label既可以定義對象時附加，也可以管理對象時操作標簽。標簽不是唯一的，很多對象可能有相同的標簽（這不廢話嗎？？？）
????????label可以將結構映射到集群對象上，形成一個與現實管理結構同步的，松耦合的，多為的對象管理結構。因此我們不需要在客戶端存放這些關系。通過selector的查詢和篩選建立這種松耦合的管理關系。
????? ? 示例：生產環境服務service1,上線前測試的內部服務service2；
service1,service2分別通過selector關聯了不同的pod(2)。pod2,3,4；pod1(pod提供后端服務支撐)
pod2,3,4；pod1分別通過selector關聯了不同的node(s)。node2,3;node1（k8s普通節點提供服務調度運行）
????這樣，通過多層次多維度的標簽定義，一個對應現實管理結構的對象關系就建立起來了。不同角色可以在同集群完成不同工作，互不影響。
---
????Annotations：將任意非標識性元數據附加到對象上，這是與標簽的區別，標簽數據是用于標識對象的數據，用于選擇對象，annotations不能用于標識，選擇對象。
????????annotations也是鍵值對形式出現，可以是結構化或者非結構化，甚至可以包含標簽中不允許出現的字符。常見可以記錄在數據的注解中的信息包括：創建，版本，debug后端信息等等。例如時間戳，版本號，對象哈希值.等等；用戶，工具，系統信息等
????????工具和庫可以檢索并使用這些Annotations元數據，以實現邏輯
????????將數據作為注解注入對象，有利于創建用于部署，管理和內部檢查的共享工具或客戶端。
查看全部 -
6-1 k8s基本概念
是深入學習k8s的基本條件
pod，deployment等，有一個共同的抽象稱呼，k8s object
k8s對象：一種持久化，用于表示集群狀態的實體
????聲明式的記錄，一般用yaml描述對象
? ? k8s對象的集合即表示當前k8s的狀態。k8s對象可以表示，有哪些容器化應用在運行，容器運行在哪個node上，有哪些可以被應用使用的資源，應用的行為策略是這么樣的，例如重啟，升級，容錯策略等
? ? k8s對象通過api來管理；kubectl其實也是調用api來實現命令功能的，通過api可以實現對象的增刪改查；管理k8s對象的過程就是管理，運維k8s的過程；k8s controller manager就是通過對象控制器使對象保持在期望狀態，換句話說，k8s的工作就是讓k8s對象保持在期望狀態，這樣k8s集群本身就在期望狀態了。
k8s對象模型，面向對象
靜態屬性：
????Kind：對象類型，如Pod,Service
????Metadata:元數據
????Spec：對象規格信息，不同對象的spec不同，可以參照面向對象基類與子類的關系
操作方法：
????增刪改查，Create,Get,Update,Delete,每種對象都有這些方法，通過API可以對對象的方法進行調用
動態信息：
????k8s對象的創建就好比如一個類被實例化了，狀態變成動態信息保存在etcd中，k8s狀態的變化是觸發k8s各組件工作的起點，k8s的工作就是講k8s對象一直保持期望狀態。
查看全部 -
5-3 node組件
除了安裝了master組件的Node，其余node都會承載工作負載，安裝容器引擎和其他的組件kubelet,kube-proxy;master node上也安裝了Node組件，它負責組件的生命周期 ，服務抽象的管理；
master組件自身也是運行在pod中的；
Node：是K8s集群中真正的工作負載節點
????（普通節點組件是每個節點必須安裝的組件，master節點也不例外）
????k8s集群由多個node共同承擔工作負載，pod被分配到某個node上執行（實例見識過了）
????k8s通過node controller對node資源進行監控管理，支持動態添加刪除node
????每個集群的每個node上都會部署kubelet和kube-proxy
---
kubelet:節點的基礎組件，無論是master還是普通node節點都會部署
????每個節點啟動會拉起kubelet，管理組件的生命周期唯一一個非容器形式的服務進程組件；
????通過api server監聽etcd的pod的數據變化，獲取歸屬該節點的pod清單，本地容器引擎交互實現pod的生命周期管理，（master處理所有控制，所以所有指令都是從master過來的，即以kubelet為橋梁，通過master的etcd信息來伸縮一般nodes的pod）
????通過api server注冊node信息
????監控node資源占用狀況，定期向master匯報；
---
kube-proxy:他也是在節點啟動時被拉起
????提供service抽象概念，將service的請求負載均衡到pod，即kube-proxy是service的代理和負載均衡器
????proxy分發策略從用戶型代理功能編程了現在的iptables mode,不是在用戶層監聽端口了
????支持nodeport mode，將集群暴露，從外部訪問集群內的service
查看全部 -
5-2 Master組件
Master組件是K8s Pod集群邏輯上的控制中心（一個Pod有若干個master節點和若干個普通nodes節點）
master內基本組件：API Server;Scheduler;Controller Manager;Etcd;
Master組件是K8S的Pod集群的控制平面：
????每個pod集群的控制命令都會傳遞到master組件并執行；
????每個k8s的集群都至少有一套master組件，如果master組件失效，怎么失去對k8s pod集群的控制，所以一般會定義多個master組件實現k8s集群的高可用控制能力。
????每個master組件都包括api server, scheduler,controller manager三個組件和一個etcd配置中心數據庫
---
API Server是master組件的中樞（之所以說控制命令都要經過master，最主要是因為master內的API Server），master中其他組件都通過API Server的API接口實現各自的功能，
????是提供k8s集群控制RESTFUL API的唯一組件，即集群控制的唯一入口；
????是集群內，各個組件通信的中樞；（不僅內外通訊，而且內內通訊也要經過API Server）
????只有API Server（master節點）才能與Etcd通訊（增刪改），其他組件只能通過API Server訪問執行狀態？？？（非master訪問Etcd只能得到狀態信息？？？:查）
????API Server提供集群控制的安全機制
---
Scheduler
????先通過API Server的Watch接口監聽到新建Pod副本信息后，通過調度算法為該Pod選擇一個最合適的Node
????支持自定義調度算法
????默認調度算法先預選再優選
---
ControllerManager
????集群內部的管理控制中心，管理k8s對象模型之一Controller
????針對每一種具體資源都有相應的controller，而controllerManager管理每個controller，使旗下的資源始終處于“期望狀態”；每個controller通過API Server提供的接口，實時監控每個資源對象的當前狀態。
? （每個controller的運行邏輯：獲取資源期望狀態，獲取資源當前狀態，將當前狀態轉變成期望狀態）
---
Etcd 是k8s集群主數據庫，保存資源對象和狀態信息
????默認與master組件部署在一個node上；如果希望在生產環境部署高可用的k8s集群，就要先部署高可用的Etcd集群，作為k8s的后端數據庫
????Etcd的數據變更，安全管理通過API Server進行，k8s各個組件實時通過API Server的Watch接口跟蹤比對Etcd資源期望狀態和實際狀態的差異，自動恢復資源到期望狀態，實現資源控制的目的，手工修改Etcd的數據是不被推薦的
查看全部 -
5-1 k8s架構全圖解釋
k8s集群是由一組節點nodes組成，節點可以是物理服務器，可以是虛擬機，k8s平臺就運行在這些節點上面；
每個節點上都安裝了node組件(kubelet,kube-proxy),
其中安裝了master組件的叫作master node,老版本也成為miniNodes，他們是真正運行負載的節點。
miniNodes的node組件的kubelet跟master node交互，維護miniNodes的pod的生命周期。
數據存儲中心 etcd,是一個數據庫,存儲了所有對象和狀態
集群維護的命令行工具kubectl,用戶以命令行方式與集群交互，操作集群
查看全部 -
4-1 演示service,pod的部署，pod伸縮等功能
官方推薦先部署service再部署Pod，因為部署容器pod的時候，會把service信息以環境變量的形式注入到pod，
官方推薦用內部DNS域名訪問service，而不推薦用環境變量訪問，兼容了以前必須依賴環境變量訪問的應用。
k8s常用yaml定義對象
（注意：k8s總是安裝在linux,所以熟悉Linux命令是基礎）
yaml常見鍵值對意義：
apiVersion:當前yaml使用的api版本
kind：聲明對象類型
metadata：
????name:定義元數據的name
spec:規格說明
????type:聲明kind的類型，NodePort將服務暴露到k8s集群之外
????selector：跟label xxx匹配后選項
????????app:......
ports:一組poort,跟spec.type對象，用NodePort表示這里的port是每臺node監聽的端口，
????port：虛擬的端口，不真實存在
????targetPort：容器監聽的端口，到達service的流量會被負載均衡到targetPort上
????nodePort：向外暴露的訪問端口，外網訪問的就是它
通過create命令創建service服務
kubectl create -f 配置文件.yaml --record
通過get命令查看命令是否創建成功了
kubectl get svc|grep 服務名
通過describe查看詳細信息
kubectl describe svc/服務名
（如果沒有部署pod，那么Endpoints對象為none）
如果此時訪問：curl ip地址:nodePort/服務，就會被refused拒絕
---
k8s服務有自動注冊，發現機制，通過內部DNS供多服務發現，交互
使用run命令啟動busybox容器查看服務內部發現地址，即內部域名
kubectl run -i --tty busybox --image=busybox --restart=Never
在busybox使用nslookup命令查看DNS地址
nslookup 服務名
---
部署pod
官方推薦不直接部署pod，而是通過deployment controller部署pod,(怕我們配置得不完全吧？)
linux查看定義好的deployment controller的yaml配置文件
vi 文件名
spec:
????replicas:? ?部署后pod的個數
????template:pod的模板類型,子對象都是模板的具體配置信息
????????metadata：模板元信息
????????????labels:? 通過這個label匹配pod
????????????????app:
????????spec：是pod的規格信息，包括容器的名字，鏡像信息，鏡像拉取...
通過kubectl的create命令創建deployment
kubectl create -f hello-deployment.yaml --record=true
通過get命令查看deployment創建結果
kubectl get deployments
出現一個列表，desired:期望的pod的副本數，current：當前存在pod的副本數，up-to-date:升級到最新的副本數，available:可以給客戶提供服務的pod副本數，age：部署了多久
再敲一次查看服務詳情，可以發現EndPoint有兩個pod的地址了
再訪問一次service,接收請求并通過自動選擇容器處理服務邏輯，并響應請求
---
測試pod的負載均衡
先查看pod信息
kubuctl get pods|grep 服務名
復制pod名，新開命令行，實時監測運行日志的查看pod在接收到請求后的處理信息
kubuctl logs -f pod名
再通過curl發起多次請求,
---
服務伸縮
根據服務流量大小改變pod的副本數，可以自動？
手動修改pod的副本數，直接修改depoloyment配置文件：
使配置文件生效命令：
kubectl apply -f 配置文件
查看pod副本命令：
發起多次請求
---
服務的版本升級和回退
spec.template.spec.containers.image是容器版本，可以手動修改，
保存，再apply生效
然后用rollout status命令升級容器
kubectl rollout status deployment/xxx-deployment
發出請求，查看pod的版本信息
undo命令是回退到上一版本：
kubectl rollout undo deployment/xxx-deployment
發出請求，查看pod的版本信息
查看全部 -
4-1 k8s集群初體驗
居然說這個DEMO相當于編程語言的Hello world?
這是一個單service的應用，service后面是若干個實際支撐的Pod，Pod由Deployment控制器進行部署 外部發送到Hello Service的某個請求被自動負載均衡到某個Pod業務容器，容器返回Hello Kubernetes字樣的應答。
演示環境：一個master,兩個node
kubernetes集群v1.7.3;鏡像倉庫hub.docker.com;
kubernetes 提供的kubectl命令kubectl get nodes獲取集群的節點列表
查看全部 -
3-3
云原生應用的k8s相當于傳統云平臺應用的linux，或者說，k8s就是云平臺的linux
查看全部 -
3-2
k8s是容器編排管理平臺
相對于傳統的虛擬化技術，容器技術在鏡像大小，執行效率，資源利用率方面都有較大優勢，但是單一容器并不能給開發者帶來太大幫助，從虛擬機過度到容器顯得沒有必要，多容器需要并發協同工作，支持跨主機管理才有意義，我們需要一個多容器管理平臺，k8s是解決方案之一。
管理特點：pod，controllers,configmap,secret等；資源配額與分配管理；健康檢查，自愈，伸縮，滾動升級。
k8s是微服務支撐平臺
k8s采用微服務架構，
支撐特點：服務發現，服務編排，路由支撐；快速部署，自動負載均衡；對有狀態服務的支持。
k8s相當于新一代openstack,是可移植的云平臺
docker將k8s集成到調度引擎等等，k8s成為通用層
平臺特點：為用戶提供簡單一致的應用部署，伸縮，管理機制；云上應用可以跨云遷移或混用云供應商。
為什么選擇k8s作為容器標準
生態角度：成熟先進；傳統云供應商全面支持
功能角度：使應用擺脫鎖定，支持跨云；先進的Pod，Controllers管理模式；支持微服務抽象：服務注冊，發現和自動負載均衡
查看全部 -
3-1 k8s是什么
功能角度，容器的管理平臺；應用角度，微服務的支撐平臺；生態圈角度，可移植的云平臺。
查看全部 -
2-1
模式變遷：
從前，以物理機為基本單元管理應用。想部署新應用，需要購買一臺/一組新的物理機器,應用直接在物理機上構建部署，運行，大多數都是一對一定制版。
代表：IBM,Sun
然后，為了提高計算機資源利用率和降低使用應用成本，以拆分物理機，聚合離散計算機資源的方式，將一臺物理機拆分成若干個虛擬機，即虛擬機作為基本計算單元管理應用。
解決方案代表：VMware,Xen,KVM
谷歌的基于虛擬化推出了AWS，開啟了基礎設施即服務IaaS的市場
接著，虛擬化成熟期，OpenStack發布，又稱云計算時代，以云的形式部署應用，
解決方案代表：IaaS，PaaS平臺即服務,SaaS軟件即服務
全球企業有一半計算資源都放到了公有云上，
解決方案代表：AWS,Azure,阿里云,谷歌云
后來，云的弊端也凸顯了，啟動慢，效率低，每個云是定制的，移植性差，就在這時候，Docker公司整合了已有技術，推出內核容器技術的標準鏡像，與虛擬機相比，效率高，移植性好，啟動快，計算基本單元從虛擬機變成了Docker容器鏡像，
但是光有容器不能完全體現虛擬機過渡到容器的優勢，所以又提出了云原生概念，基于容器推出一整套原生環境，更加智能，敏捷地管理應用。
查看全部
舉報