花椒服務端k8s技術實踐

時間 2019-11-15

標籤花椒服務 k8s 技術實踐简体版

原文原文鏈接

奇技指南隨着容器技術的快速發展，諸如Kubernetes（如下簡稱k8s）此類容器編排技術應運而生，當人們逐漸意識到容器是雲計算的將來，愈來愈多的人投入到容器技術的懷抱，也就是在這短短几年裏，k8s贏得了這場戰爭，實際上，k8s的帶來的影響已經遠超容器管理領域自己。本文轉載自花椒技術公衆號java

前言

隨着容器技術的快速發展，諸如Kubernetes（如下簡稱k8s）此類容器編排技術應運而生，當人們逐漸意識到容器是雲計算的將來，愈來愈多的人投入到容器技術的懷抱，也就是在這短短几年裏，k8s贏得了這場戰爭，實際上，k8s的帶來的影響已經遠超容器管理領域自己。服務網格的概念已經走進你們視線，而這也剛好讓人們意識到，k8s豈不正是實現微服務的一種解決方案，這也進一步將k8s推向風口浪尖。nginx

k8s的核心概念

本文是創建在已經對docker技術有必定了解的基礎上的，就再也不贅述docker相關的概念了，初步介紹一下k8s的核心概念和思想，目的是讓你們快速熟悉，更好理解接下來的內容。docker

POD

這是k8s裏定義的最小單元，由於k8s是源於google，而該項目目標也不只僅是支持docker這一種容器技術，抽象出一個pod的概念，其實k8s自己不關心pod內部是什麼類型容器，能夠有多個容器在pod內啓動（官方建議單一pod單一容器），pod內容器共享網絡,共享存儲，pod能夠由控制器啓動，控制器也就是k8s負責編排的組件之一，常見的有json

Deployment，經過指定副本數量等屬性，根據配置的pod模版，部署無狀態的服務，可以提供強力的回滾，滾動更新等能力，這個也是最經常使用的一種；微信
Statefulset，有狀態副本集，通常部署etcd，elasticsearch等等這種有狀態的服務，通常同時會掛載存儲卷（也是k8s中定義的一種對象）；網絡
DeamonSet，守護進程集，通常指定節點部署一些服務，好比cpu監控等；併發

Service

pod被啓動後，在k8s中是沒法從外部訪問的，這時候就須要service將其暴露出去，service至關於pod的負載均衡器，通常經過如下方式：負載均衡

CluserIP(默認)，經過iptables作nat規則轉換，將流量轉到相應的pod內,集羣內部服務之間訪問就是經過這種方式；elasticsearch
NodePort，暴露主機隨機端口,kube-proxy組件將相應規則寫入iptables表，訪問主機端口將會被引流至相應的pod，這種方式可以對集羣外部暴露服務；微服務
LoadBalancer，NodePort的變種，通常由具體的雲服務商實現，好比阿里雲，一旦service建立後, 會自動建立一個負載均衡，會自動作80:3xxxx端口的映射，流量經過負載均衡，會轉到相應主機端口，最終根據iptables規則將流量轉發到pod內；
ingress, 做爲7層http負載，做用至關於反向代理的nginx的服務，流量經過一臺負載均衡進來，可由ingress配置域名或者路徑，轉發到相應service;

這裏只是簡單介紹核心概念，深刻學習的話請移步官方文檔

技術對比

有幾種競爭技術可用於管理大型Docker部署和基於容器的服務。你可能據說過其中一些退役的解決方案：Docker Swarm，Apache Mesos，OpenStack Magnum等。然而，如今Kubernetes已經淘汰了其中大多數競爭對手會被與k8s拿來對比的，應該就Docker Swarm能夠應戰，swarm是docker原生的集羣工具，部署簡單，並且對於熟悉docker的人，學習成本低，而k8s最令開發者頭疼的莫過於很是高的複雜度，和學習成本，不過目前不論是阿里雲仍是其餘雲服務商，都同時提供了這兩個解決方案，並且都有在生產環境大規模使用的案例，這裏拿比較成熟的阿里雲的這兩種解決方案對比：

資源調度這一點上二者都都作到能夠按集羣資源調度分配，只是調度的粒度不一樣，swarm是容器，而k8s是pod；
自動伸縮 swarm自己不支持，可是依靠阿里雲實現了該功能，而k8s有水平自動拓展HPA，能夠根據監控數據進行自動伸縮；
負載均衡 k8s自己提供了多種方案，內部service是經過iptables實現，外部7層負載均衡有ingress層，阿里雲也提供了LoadBalancer支持負載均衡； swarm自己沒有負載均衡層，不過阿里雲也經過
滾動更新 swarm目前也支持了滾動更新，而且在阿里雲上實現了藍綠部署等，k8s自己的deployment支持滾動升級
容災恢復 swarm沒有作到，在節點掛掉的狀況下，服務沒法快速恢復； k8s是可以作到這一點，副本控制器可以維持副本數量，節點掛掉也會迅速從其餘節點啓動必定數量的副本，而且比較完善的監控也能夠及時發現問題；

而從swarm自己來看的話，因爲其是集成到docker中的，swarm集羣只會有兩層交互，容器啓動是毫秒級，要遠快於k8s, 可是兼容的docker API也使得其沒法進行更精細的管理，相對的k8s有副本控制器能夠監控並維護容器的生命週期，有pod能夠進行更加精細的管理，總結來看，其實swarm自己的重心是放在了docker容器編排上，而k8s的倒是在考慮如何管理，事實上，如今仍是愈來愈多的人傾向於使用k8s，也正是看中了其諸多優勢。

實踐

咱們在使用自建集羣的過程當中，因爲官方的dashboard操做yaml的學習成本很高，因此咱們使用了wayne這個開源的k8s管理項目，其功能包含但不限於dashbaord的功能，權限管理，人員劃分，部門劃分等，屬因而一個面向大型項目團隊的k8s集羣管理後臺，如下是一些實例

在使用過程當中，改後臺，確實是帶來了許多便利，能夠免去k8s的yaml配置的學習成本，經過可視化界面完成服務的建立，咱們前期的一些試驗性服務都是經過這個部署；

可是同時也存在一些弊端，在k8s的基礎之上，抽象出了更多的概念，包括項目劃分，權限管理等等，這些模塊的目的是爲了針對大型團隊，控制項目人員，分配資源，不過同時，這些額外的概念對於使用者，尤爲是對k8s也不熟悉，只是關心如何部署服務的開發人員，會混淆k8s自己的概念，致使學習成本進一步上升，針對小型團隊，一些複雜的資源劃分，項目劃分功能反而顯得冗餘。

固然，正如前文說的，目前咱們仍是傾向因而用現有的雲提供商所實現的k8s解決方案；在阿里雲上的實踐也證實了其帶了的許多便利，確實會極大減小集羣維護人員的負擔，其相對完善的後臺，也可以知足絕大多數狀況的開發人員使用，其優點還主要體如今如下方面： 1,阿里雲維護的高可用集羣，免去了自維護的所面臨的機房，網絡諸多問題；

2,負載均衡的支持，不須要本身搭建配置ingress組件，建立服務會自動生成負載均衡

3,阿里雲鏡像倉庫支持，能夠直接從鏡像建立pod，且有建立模版，能夠輕鬆的建立服務；

4,雲盤等文件系統支持，很是方便的聲明和掛載存儲卷；

優秀的監控報警系統，從多個維度，對服務進行詳細的監控，靈活配置報警；

搭建注意事項

想要更加深刻的理解和使用k8s, 經過自建k8s集羣是一種不錯的手段，搭建方法參考官網便可；這裏有一些搭建過程當中的值得注意的一些細節：

1,建議使用阿里的源

cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=0 EOF

2,若是遇到kubelet和docker的文件驅動不一致，能夠修改docker的驅動

//;/etc/docker/daemon.json { "exec-opts": ["native.cgroupdriver=systemd"] }

3,kube-proxy默認使用iptables，考慮性能能夠改成ipvs