k8s源碼

⑴ 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部署fabric,用minikube部署的k8s集群環境，kube-dns出現了問題

1. 安裝kubectl

curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl && chmod +x kubectl && sudo mv kubectl /usr/local/bin/
1
下載指定版本，例如下載v1.9.0版本

curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.9.0/bin/linux/amd64/kubectl && chmod +x kubectl && sudo mv kubectl /usr/local/bin/
1
2. 安裝minikube

minikube的源碼地址：https://github.com/kubernetes/minikube

2.1 安裝minikube

以下命令為安裝latest版本的minikube。

curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/
1
安裝指定版本可到https://github.com/kubernetes/minikube/releases下載對應版本。

⑶ 如何在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

⑷ 如何閱讀k8s源碼

懂golang 。會用翻譯

⑸ k8s怎麼解決mysql故障遷移的

k8s怎麼解決mysql故障遷移的
有兩種方法： 直接用yum源進行安裝yum -y install mysql-server 源碼安裝去mysql官網下載你需要的版本，解壓，創建用戶，/usr/local/mysql5.6/scripts/mysql_install_db --basedir=/usr/local/mysql5.6 --datadir=/data/mysql5.6 --user=mysql

⑹ 如何訪問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 的一些記錄。

⑺ kubernetes源碼是java嗎

Kubernetes（簡稱k8s）是Google在2014年6月開源的一個容器集群管理系統，使用Go語言開發，用於管理雲平台中多個主機上的容器化的應用，Kubernetes的目標是讓部署容器化的應用簡單並且高效,Kubernetes提供了資源調度、部署管理、服務發現、擴容縮容、監控，維護等一整套功能。，努力成為跨主機集群的自動部署、擴展以及運行應用程序容器的平台。 它支持一系列容器工具, 包括Docker等。

所以注意：K8s學習有一個前提條件，需要先掌握docker，如果你沒有docker基礎的話，那還不能學習 K8s k8s它底層的部署容器的那麼容器本來就是docker。

還可以通過B站上這個視頻教程了解更多：

⑻ flink 1.10 1.12區別

flink 1.10 1.12區別在於Flink 1.12 支持了 Flink SQL Kafka upsert connector 。

因為在 Flink 1.10 中，當前這類任務開發對於用戶來說，還是不夠友好，需要很多代碼，同時也會造成 Flink SQL 冗長。

Flink 1.12 SQL Connector 支持 Kafka Upsert Connector，這也是我們公司內部業務方對實時平台提出的需求。

收益：便利用戶有這種需要從 kafka 取最新記錄操作的實時任務開發，比如這種 binlog -> kafka，然後用戶聚合操作，這種場景還是非常多的，這能提升實時作業開發效率，同時 1.12 做了優化，性能會比單純的 last_value 性能要好。

Flink Yarn 作業 On k8s 的生產級別能力是：

Flink Jar 作業已經全部 K8s 化，Flink SQL 作業由於是推廣初期，還是在 Yarn 上面進行運行，為了將實時計算 Flink 全部K8s化。

所以我們 Flink SQL 作業也需要遷移到 K8s，目前 Flink 1.12 已經滿足生產級別的 Flink k8s 功能，所以 Flink SQL K8s 化，打算直接使用社區的 On k8s 能力。

風險：雖然和社區的人溝通，Flink 1.12 on k8s 沒有什麼問題，但是具體功能還是需要先 POC 驗證一下，同時可能社區 Flink on k8s 的能力。

可能會限制我們這邊一些 k8s 功能使用，比如 hostpath volome 以及 Ingress 的使用，這里可能需要改底層源碼來進行快速支持（社區有相關 JIRA 要做）。

⑼ Docker生態會重蹈Hadoop的覆轍嗎

一、Docker的興起和Hadoop何其相似
2015年說是Docker之年不為過，Docker熱度高漲，IT從業人員要是說自己不知道Docker都不好意說自己是做IT的。2016年開始容器管理、集群調度成為熱點，K8s開始成為熱點。但這一幕和2013年的Hadoop大數據何其相似，當年你要說自己不知道大數據，或是知道大數據不知道Hadoop，那必然招來鄙視的眼光。
雲計算喊了這么久，從來沒有像Docker這么火過，究其原因不外乎兩條：
1、開發者能夠用Docker，開發者要一個開發環境，總會涉及到種種資源，比如資料庫，比如消息中間件，去裝這些東西不是開發人員的技能，是運維人員的技能。而用Docker去Pull一個mySQL鏡像,或是Tomcat鏡像，或是RabbitMQ鏡像，簡易輕松，幾乎是零運維。做好了應用代碼，打一個Docker鏡像給測試或是運維人員，避免了從前打個程序包給測試或是運維人員，測試或運維人員要部署、配置應用，還得反反復復來麻煩開發人員，現在好了，丟個Docker鏡像過去，讓運維人員跑鏡像就可以，配置在鏡像里基本都做好了。
這正好滿足了DevOps的要求，所以DevOps也一下熱起來了。開發者是一個巨大的市場，是海量的個體，通過類似於病毒式的傳銷，Docker一下在開發者中熱起來了。
2、鏡像倉庫和開源，誰都可以用，Docker鏡像庫非常豐富，誰做好一個鏡像都可以往公有倉庫推送，開發人員需要一個環境的時候，可以到Docker鏡像倉庫去查，有海量的選擇，減少了大量無謂的環境安裝工作。而通過開源，又開始大規模傳播。
我們再來回顧看看2010-2013年，大數據的名詞火遍大江南北，各行各業都在談大數據，但是落到技術上就是Hadoop，還記得2012年的時候，和Hadoop沒啥毛關系的VMWare也趕緊的做了一個虛機上部署Hadoop的serengeti，誰家產品要是和Hadoop不沾點邊，不好意思說自己是IT公司。Hadoop當年的熱度絕對不亞於2014-2015的Docker。而且時間上有一定的連續性，2014年開始，Hadoop熱度達到頂點，開始逐漸降溫，標志事件就是Intel投資Cloudera。而Docker是從2014年開始熱度升高的。
再看Hadoop為何在2010年前後開始熱起來，之前的大數據都是數據倉庫，是昂貴的企業級數據分析並行資料庫，而Hadoop是廉價的大數據處理模式，通過開源和X86廉價硬體，使得Hadoop可以大規模使用，而互聯網時代產生的海量數據雖然垃圾居多，但是沙裡淘金，也能淘出點價值，Hadoop正好迎合了這兩個需求，雖然Hadoop的無論是功能還是性能遠比MPP資料庫差，但做簡單的數據存儲、數據查詢、簡單數據統計分析還是可以勝任的，事實上，到目前為止，大多數的Hadoop應用也就是數據存儲、數據查詢和簡單的數據統計分析、ETL的業務處理。
Docker和Hadoop的熱起來的原因不同，但是現象是差不多，開源和使用者群體大是共同要素。
二、Hadoop從狂熱走向了理性
Hadoop最熱的時候，幾乎就是要replace所有資料庫，連Oracle也面臨了前所未有的沖擊，甚至Hadoop成了去IOE的Oracle的使命之一。在狂熱的那個階段，客戶怎麼也得做一兩個大數據項目，否則會被同行瞧不起，各IT廠商也必須推出大數據產品，否則可能成為IT過時的典範，這不IBM成立了專門的大數據部門，打造了一個以Hadoop為核心的龐大的大數據解決方案。
Intel雖然是做晶元的，但是大數據必須摻和，成立大數據部門，做Intel Hadoop 。連資料庫的老大Oracle也憋不住了，做了個大數據一體機。
任何曾經狂熱的新技術都會走向理性，Hadoop也不例外，只不過，這個進程還比較快。隨著大數據的大躍進，隨著Hadoop的應用越來越多，大家發現在被誇大的場景應用大數據效果並不好，只在特定場景有效，Hadoop進入理性發展階段，比如一開始Hadoop據取代MPP資料庫，取代數據倉庫，取代Oracle，完美支持SQL等等均基本成為泡影。這其實本來是一個常識，任何技術都有其應用場景，誇大應用場景，任意擴展應用場景只會傷害這個技術的發展。
「這和目前無限誇大Docker的應用場景有異曲同工之妙，比如Docker向下取代虛擬化，Docker向上取代PaaS之類，幾乎成了雲計算的唯一技術，這種論調一直充斥各種Meetup/論壇。雖然技術從誇大到理性需要時間，但是理性不會總是遲到。
Hadoop技術在發展，大數據的相關技術也在發展，Hadoop一直被詬病的處理速度慢，慢慢的被Spark/Storm等解決，特別在流數據處理領域。
所以，時至今日，人們對Hadoop的態度趨於理性，它只適合在特定場景使用，可是，當初那些在Hadoop不太適用的場景使用了Hadoop的客戶交了學費的事情估計沒人再提了。Docker估計也是一樣的，總有在誇大的場景中交學費的客戶，可是只是客戶沒眼光嗎?和無限誇大某種技術的佈道師無關么?
再反觀大數據和Docker在全球的發展，在美國，無論是Hadoop和Docker並沒有像國內這么狂熱過。Hadoop技術來源於Google，成型於Yahoo(DougCutting)，而炒作卻是在國內。同樣，Docker也在走這么個流程，在美國沒有這么多的Docker創業公司，主要就是Docker，然後各大廠商支持，創業公司和創投公司都知道，沒有自己的技術或是技術受制於人的公司不值得投資，既然Docker一家獨大，再去Docker分一杯羹會容易嗎?
而國內二三十家的Docker創業公司，沒有一家能對Docker/K8s源碼有讓人醒目的貢獻(反倒是華為在K8s上有些貢獻)，但是都在市場上拼嗓門，不是比誰的技術有潛力最有市場，而是比誰最能佈道誰嗓門大，誰做的市場活動多，某Docker創業公司據說80%的資金用在市場宣傳、Meetup上，而且不是個別現象，是普遍現象。反應了某些Docker創業者的浮躁心態。

⑽ k8s和docker區別是什麼

k8s和docker區別有以下幾點：

1、k8s是一種開放源碼的容器集群管理系統，能夠實現自動化部署、擴展容器集群、維護等功能。

2、Docker是一種開放源碼的應用容器引擎，開發者可以將他們的應用和依賴打包在一個可移植的容器中，發布到流行的Linux機器上，也可以實現虛擬化。

3、k8s的全稱kubernetes。它是一個完整的分布式系統支撐平台，集群管理功能齊全。Kubernetes同時提供完善的管理工具，涵蓋了開發、部署、測試、運行監控等各個環節。

4、Docker是一種開放源碼的應用容器引擎，允許開發人員將其應用和依賴包打包成可移植的鏡像，然後發布到任何流行的Linux或Windows機器上，也能實現虛擬化。該容器完全使用沙箱機制，彼此之間沒有任何介面。