㈠ k8smaster重啟後無法打開Dashboard
k8smaster重啟後無法打開Dashboard的解決方法如下：
部署到dashboard之前檢查所有的步驟都沒有出現錯誤，可是安裝了dashboard插件之後無論是通過 NodeIP:NodePort的方式 還是通過 proxy 或是 kube-api的方式 都一直無法訪問，瀏覽器也沒有提示任何錯誤，只是一直在載入，頁面也是空白一片。接下來開始排查問題
首先，查看dashboard被k8s分配到了哪一台機器上
發現dashboard部署到了10.12.32.148這個節點上。
接著，查看dashboard的集群內部IP，
發現他的集群IP為10.254.105.242，接著，由於flannel網路已經打通，我嘗試著在各個node上curl這個IP，可是發現，除了10.12.32.148這個機器自己curl返回了結果外，其他的所有機器都沒有相應。此時，是flannel網路的問題，可如果是flannel網路的問題，那麼之前ping網關的時候就應該不通。
㈡ 什麼是K8S
k8s全稱kubernetes，這個名字大家應該都不陌生，k8s是為容器服務而生的一個可移植容器的編排管理工具，越來越多的公司正在擁抱k8s，並且當前k8s已經主導了雲業務流程，推動了微服務架構等熱門技術的普及和落地，正在如火如荼的發展。想要了解更多，我推薦你去看看時速雲，他們是一家全棧雲原生技術服務提供商，提供雲原生應用及數據平台產品，其中涵蓋容器雲PaaS、DevOps、微服務治理、服務網格、API網關等。大家可以去體驗一下。
希望能給您提供幫助，可以給個大大的贊不。
㈢ k8s 怎麼訪問 service的clusterip地址
service的cluster-ip是k8s系統中的虛擬ip地址
只能在內部訪問。
如果需要在外部訪問的話
可以通過NodePort或者LoadBalancer的方式。
㈣ 如何訪問k8s集群內部署的mysql服務
雖然 kubernetes 社區一直在努力使得有狀態應用成為一等公民，也推出了 statefulset 控制器支持 pod 的順序部署，穩定的域名訪問和存儲訪問。但鑒於 MySQL 部署運維的多樣性和復雜性，在 kubernetes 上部署 MySQL 仍然要面臨眾多挑戰。
1、業務流量入口的配置方式
傳統虛擬機環境下，我們通過虛IP的方式，讓業務應用都配置事先定義的一個虛IP為鏈接資料庫的地址，然後由高可用服務保證虛IP始終能被路由到master資料庫。在kubernetes中，出現了一層網路插件屏蔽了底層網路拓撲，高可用服務管理虛IP的方式需要隨之適應調整，比如通過service結合標簽完成虛IP的漂移，但service本身是kubernetes提供的一項功能，其可靠性和性能都取決於kubernetes服務的穩定。以性能來說，service是kubeproxy組件通過配置iptables實現的，當iptables規則較多時不可避免的會產生時延，需要我們針對性的解決。
2、容器隔離帶來的監控視野問題
在 kubernetes 中，如果將 MySQL 製作為 container 運行在一個 pod 中，container 會將 MySQL 進程和運行環境隔離在一個單獨的 namespace 中。監控組件在獲取 MySQL 的一些 metirc 時，可能不得不進入與 MySQL 同一個 namespace 中，在部署和設計監控組件時需要考慮到這些限制。
3、存儲在 kubernetes 中，支持配置各種不同的存儲。
如果使用本地存儲 local persistent volume，則需要綁定 MySQL 在一個固定的節點，這就完全浪費了 kubernetes 靈活調度的天然優勢；而如果使用遠程共享存儲，確實是將 MySQL 進程與其存儲完全解耦，使得 MySQL 進程可以在任意節點調度，然而考慮到高 I/O 吞吐量的情況，就不是那麼美好了。設計時需要考量遠程存儲是否能夠滿足 MySQL 的帶寬要求。
4、高可用/備份恢復
kubernetes 提供的 statefulset 控制器只能提供最基本的部署，刪除功能，無法實現完善的 MySQL 集群高可用/備份恢復操作。對於有狀態應用的部署，仍需要定製開發，所以多數公司提供了定製的 operator 來完成應用容器的管理。比如 etcd operator，MySQL operator，後文將為大家詳述我測試使用 MySQL operator 的一些記錄。
㈤ k8s怎麼控制crd超時
添加狀態和伸縮配置。
當你創建一個新的CustomResourceDefinition (CRD)時，Kubernetes API伺服器將為你指定的每個版本創建一個新的RESTful資源路徑，我們可以根據該api路徑來創建一些我們自己定義的類型資源。CRD可以是命名空間的，也可以是集群范圍的，由CRD的作用域(scpoe)欄位中所指定的，與現有的內置對象一樣，刪除名稱空間將刪除該名稱空間中的所有自定義對象。
在 Kubernetes 中一切都可視為資源，Kubernetes 1.7 之後增加了對 CRD 自定義資源二次開發能力來擴展 Kubernetes API，通過 CRD 我們可以向 Kubernetes API 中增加新資源類型，而不需要修改 Kubernetes 源碼來創建自定義的 API server，該功能大大提高了 Kubernetes 的擴展能力。
㈥ 如何入門k8s
Kubernetes（簡稱K8S） 是Google開源的分布式的容器管理平台，方便我們在伺服器集群中管理我們容器化應用。
節點（Master node and Worker node）
節點通常指的就是伺服器，在k8s中有兩種節點：管理節點（Master Node）和工作節點（Worker Node）
管理節點（Master Node）：負責管理整個k8s集群，一般由3個管理節點組成HA的架構。
工作節點（Worker Node）：主要負責運行容器。命名空間(Namespace)
k8s命名空間主要用於隔離集群資源、隔離容器等，為集群提供了一種虛擬隔離的策略；默認存在3個名字空間，分別是默認命名空間 default、系統命名空間 kube-system 和 kube-public。Object
k8s 對象(Object)是一種持久化存儲並且用於表示集群狀態的實體。k8s 對象其實就是k8s自己的配置協議，總之我們可以通過定義一個object讓k8s根據object定義執行一些部署任務、監控任務等等。POD
Pod是 Kubernetes 部署應用或服務的最小的基本單位。一個Pod 封裝多個應用容器（也可以只有一個容器）、存儲資源、一個獨立的網路 IP 以及管理控制容器運行方式的策略選項。副本集(Replica Set，RS)
是一種控制器，負責監控和維護集群中pod的副本(replicas)數，確保pod的副本數是我們期望的樣子。部署(Deployment)
表示對k8s集群的一次更新操作，是k8s集群中最常用的Object，主要用於部署應用。支持滾動升級。服務(service)
是對應用的抽象，也是k8s中的基本操作單元，一個服務背後由多個pod支持，服務通過負載均衡策略將請求轉發到容器中。Ingress
是一種網關服務，可以將k8s服務通過http協議暴露到外部。無狀態應用 & 有狀態應用
無狀態應用指的是應用在容器中運行時候不會在容器中持久化存儲數據，應用容器可以隨意創建、銷毀；如果一個應用有多個容器實例，對於無狀態應用，請求轉發給任何一個容器實例都可以正確運行。例如：web應用
有狀態應用指的是應用在容器中運行時候需要穩定的持久化存儲、穩定的網路標識、固定的pod啟動和停止次序。例如：mysql資料庫
㈦ 介面異常是什麼意思
介面異常的意思就是伺服器崩了，網路導致視頻播放失敗，介面出現了異常。
檢查自己的網路是不是已經連接成功了，網速限速沒，連接成功後再次登錄，就可以看自己想要看的視頻了。
㈧ kubernetes為什麼叫k8s
kubernetes，簡稱K8s，是用8代替8個字元「ubernete」而成的縮寫。是一個開源的，用於管理雲平台中多個主機上的容器化的應用，Kubernetes的目標是讓部署容器化的應用簡單並且高效(powerful),Kubernetes提供了應用部署，規劃，更新，維護的一種機制。
Kubernetes是Google開源的一個容器編排引擎，它支持自動化部署、大規模可伸縮、應用容器化管理。在生產環境中部署一個應用程序時，通常要部署該應用的多個實例以便對應用請求進行負載均衡。在Kubernetes中，我們可以創建多個容器，每個容器裡面運行一個應用實例，然後通過內置的負載均衡策略，實現對這一組應用實例的管理、發現、訪問，而這些細節都不需要運維人員去進行復雜的手工配置和處理。
㈨ 如何在Kubernetes中暴露服務訪問
Kubernetes概述
最近的一年，kubernetes的發展如此閃耀，正被越來越多的公司採納用於生產環境的實踐。同時，我們可以在最著名的開發者問答社區StackOverflow上看到k8s的問題數量的增長曲線（2015.5-2016.5），開發者是用腳投票的，從這一點看也無疑證明了k8s的火爆程度。
k8s來源於Google生產環境的實踐，社區活躍度很高，在github上的Star數17k+，30k+commits，同時由Google主導CNCF基金會也在強力運作k8s的社區發展，也就在幾個月前OpenStack社區宣布全面擁抱k8s，這也宣布了全球第大的開源IAAS雲社區已經選擇k8s作為容器的唯一解決方案。
談到k8s，無論怎樣的議題怎樣的開始，我們都先介紹一個k8s整體架構（如下圖所示）：
etcd 作為配置中心和存儲服務，保存了所有組件的定義以及狀態，k8s的多個組件之間的互相交互也主要通過etcd；
kube-apiserver 提供和外部交互的介面，提供安全機制，大多數介面都是直接讀寫etcd中的數據；
kube-scheler 調度器，主要干一件事情，監聽etcd中的pod目錄變更，然後通過調度演算法分配node，最後調用apiserver的bind介面將分配的node和pod進行關聯；
kube-controller-manager 承擔了master的主要功能，比如和CloudProvider(IaaS)交互，管理node，pod，replication，service，namespace等。
基本機制是監聽etcd /registry/events下對應的事件，進行處理；kubelet 主要包含容器管理，鏡像管理，Volume管理等；kube-proxy 主要用於實現k8s的service機制。提供一部分SDN功能以及集群內部的智能LoadBalancer。
本文分享的內容主要是在minion節點上的pod和service上，pod是k8s應用的具體實例抽象，而service便是這些抽象的集合。
ClusterIP & NodePort & Loadbalancer
回到本文的主題，在k8s中暴露Service訪問（無論內部還是外部），都要經過kube-proxy，比如下圖中我們定義一個Service，便可以通過訪問Service的80埠轉發到Pod的9376埠上。
kube-proxy在轉發時主要有兩種模式Userspace和Iptables。如下圖，左側是Userspace模式，也是kube-proxy默認的方式，所有的轉發都是通過kube-proxy軟體實現的；右側是Iptables模式，所有轉發都是通過Iptables內核模塊實現，而kube-proxy只負責生成相應的Iptables規則。從效率上看，Iptables會更高一些，但是需要Iptables version >=1.4.11，Iptables模式在k8s1.2版本放出，是否開啟使用還需要具體斟酌。
從Service本身看，有三種方式來暴露訪問：
ClusterIP：使用集群內的私有ip —— 這是默認值
NodePort：除了使用cluster ip外，也將service的port映射到每個node的一個指定內部port上，映射的每個node的內部port都一樣。
LoadBalancer：使用一個ClusterIP & NodePort，但是會向cloud provider申請映射到service本身的負載均衡。
LoadBalancer Provider主要有aws、azure、openstack、gce等雲平台提供。相關實現可以在k8s的源碼中看到，如下圖所示：
Ingress
Ingress也是k8s中單獨定義的對象（如下圖所示），它的作用就是實現對外暴露訪問的負載均衡，那麼它和Service本身LoadBalancer有哪些區別呢？Ingress支持L4、L7負載均衡，LoadBalancer設計上只支持L4；Ingress基於Pod部署，並將Pod網路設置成external network；Ingress controller支持Nginx、Haproxy、GCE-L7，能夠滿足企業內部使用。
在實際使用時，Ingress的架構如下圖所示：
但是在實際使用中，pod可能會產生漂移，由於Ingress Controller也是基於Pod部署，這樣Ingress對外的IP會發生變化。在企業內部都會在防火牆上給Service的訪問IP設定規則，而IP變動對這一機制是致命的，因為企業不可能經常手動修改防火牆規則。
那麼我們就需要一個VIP功能，同時也要能保證Ingress的HA。我們可以考慮在Ingress Controller基礎上增加一個keepalived，可以利用keepalived＋haproxy的機制來完成VIP的功能。要實現這一機制，可以參考並改動k8s社區中的contrib-keepalived-vip機制。
除了以上介紹的暴露服務機制，還有Hpcloud-service-loadbalancer ，它實現了支持keepalived+nginx、F5、OpenStack Lbaas這些方式，並且支持L4 & L7負載均衡，但是與k8s社區本身的發展機制並不兼容，所以一直沒有被合並到社區中。另外還有 Contrib-service-loadbalancer ，這個是社區內部正在發展的，它的想法更遠大，考慮會支持Cross-namespace、 Cross-cluster這種級別的負載均衡，同時也是設計了插件機制，目前支持Haproxy，同樣也支持L4 & L7負載均衡。
Rancher K8s中暴露服務訪問
Rancher自己實現了一個rancher-ingress-controller，它本質上是包裝了k8s-ingress-controller，在真正創建負載均衡器上它會調用Rancher Cattle API來創建Rancher自身的LB。
相關代碼也是開源的，https://github.com/rancher/lb-controller，lb-controller在啟動時候會指定provider為rancher，對應的實現也可在package provider/rancher中看到。
創建Ingress後，也可在Rancher UI上展現出來。
創建過程，可以看我錄制這段視頻教程，http://v.youku.com/v_show/id_XMTc2MDAzNjQ4OA==.html
㈩ cicd怎麼解決配置中心
cicd-wayne-2：使用wayne容器化apollo配置中心
目錄：
(1).wayne中創建命名空間
(2).wayne創建apollo項目
(3).wayne中容器化apollo
(1).wayne中創建命名空間
點擊「創建命名空間」:
選中「自動創建」會在K8S集群中創建對應的命名空間。名稱指的是在wayne中的邏輯名稱，方便wayne管理，兩者盡量保持一致。
可用機房：0.1表示cpu核數，1表示內存是1G；分別表示這個namespace中cpu和內存可以達到的上限。
(2).wayne創建apollo項目
wayne中項目的概念：
一個namespace(wayne與K8S共有)中可以部署多個項目，比如說用戶中心這個部門(對應user-namespace)下有多個項目，passport, account, user等項目；而每個項目又對應多個服務，比如passport項目對應passport-rpc, passport-web等。可以如此類比理解wayne中的管理結構。
返回前台創建項目：
後邊我們要容器化的apollo的各項服務都會放在下圖中的apollo-min項目中：
(3).wayne中容器化apollo
在前台的項目列表頁中進入項目apollo-min：
筆者提供了dev環境下的最小apollo集群容器化的配置文件，位於：
https://github.com/hepyu/k8s-app-config/tree/master/yaml/min-cluster-allinone/apollo-min
以wayne對apollo-config-server容器化舉例，admin-server與portal-server類似：
apollo-config-server有4個組件：1個Configmap, 2個Service(其中1個是nodePort暴露apollo配置服務到容器外部)，1個StatefulSet。
1.創建configmap
configmap對應wayne中的配置集中的每個配置項，創建配置集：
創建configmap，對應wayne中的「創建配置集模板」：
選擇高級配置，直接寫yaml文件：
點擊保存後：
點擊提交完成configmap配置，注意到這里只是將配置放到了wayne自己的配置資料庫中，並沒有容器化到kubernetes集群中；需要點擊發布才會將這個配置發布到kubernetes容器。
2.創建service
wayne前台選擇負載均衡：
創建負載均衡模板(對應kubernetes中的service)：
同樣選擇高級配置：
同樣方式部署nodeport類型的負載均衡/service，最終結果：
之所以有兩個負載均衡，是因為clusterIP類型的service是提供給容器內部服務使用;nodeport類型的service是暴露配置服務給容器外部，這樣容器中的apollo可以同時為容器內部和外部的應用提供配置中心的服務。
點擊發布，將負載均衡/service部署到kubernetes容器中：
3.創建StatefulSet
在狀態副本集中配置後進行發布，流程類似，不再贅述。