Kubernetes

前言

視情況更新和完善學習筆記，trying…

歷史

Kubernetes特點

輕量級，消耗資源少
開源
彈性伸縮
負載均衡: IPVS

K8S組件

K8S的一些關鍵字解釋

Borg

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-YI5k3WD0-1583118152623)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581407966287.png)]

BorgMaster

調度器或者高可用節點最好保持在3個以上的奇數。

因爲etcd集羣數量必須爲單節點個數，所以對應master一般都是單數。

最好是 3，5，7，9

scheduler

調度器

scheduler先把數據寫入Paxos鍵值對數據庫。Borglet監聽Paxos數據庫。故通過Paxos爲中間商實現scheduler請求

Kubernetes基礎概念

kubernetes和borg有一定的相似之處

K8S架構

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-DHeqoc2W-1583118152625)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581408449730.png)]

從這個表格可以看出來幾乎所有的服務都是通過api server進行分發的。

服務分類

有狀態服務：DBMS

無狀態服務：LVS APACHE

高可用集羣副本數據最好是 >= 3 奇數個

k8s內部是一個扁平化的網絡，容器之間是可以互相訪問的

Service

擁有唯一指定的名稱
擁有一個虛擬IP(Cluster IP，Service IP 或 VIP) 和端口號。每個服務進程都有一個獨立的EndPoint(IP+Port)訪問點。K8S能夠讓我們通過Service(虛擬Cluster IP + Service Port)連接到指定的Service。有了K8S內建的透明負載均衡和故障恢復機制。不管後端有多少服務進程，也不管某個服務進程是否由於發生故障而被重新部署到其他機器，都不會影響對服務的正常調用。更重要的是，這個Service本身一旦創建就不再變化，這意味着我們再也不用爲K8S集羣中服務的IP地址變來變去的問題苦惱了。
能夠提供某種遠程服務能力
被映射到提供這種服務能力的一組容器應用上

DNS服務器

域名解析

先訪問的是DNS服務器然後它解析過之後，返回服務器的ip 給用戶訪問

Socket通信

DHCP

DHCP（動態主機配置協議）是一個局域網的網絡協議。指的是由服務器控制一段lP地址範圍，客戶機登錄服務器時就可以自動獲得服務器分配的lP地址和子網掩碼。默認情況下，DHCP作爲Windows Server的一個服務組件不會被系統自動安裝，還需要管理員手動安裝並進行必要的配置。

DHCP和STATIC

Dhcp：動態獲取ip 一般都是客戶端

Static：靜態獲取ip 一般都是服務端

Dhcp Client —— dhcp 所有客戶端的信息

Static IP —— 靜態IP，不通過dhcp動態分配IP

Pod

Pod概念

自主式Pod

將每個服務進程都包裝到相應的Pod中，使其成爲在Pod中運行的一個容器(Container)，其中會有一個名爲Pause的容器，其餘的容器稱爲業務容器，這些業務容器共享Pause容器的網絡棧和Volume掛載卷。最小的封裝集合，是Kubernetes的最小管理單位。

Pause容器和業務容器之間的通信和數據交換更爲高效。

同一個Pod共享一個網絡棧，相當於本地網絡，兩個容器之間可以通過localhost訪問。(就是本地網絡下兩個容器之間的數據交互，內部可以訪問，外部無法訪問)

類似docker裏的 link 和 volume

Pod中會有多個容器(container)

控制器管理的Pod

Pod控制器類型

RelicationController & ReplicaSet & Deployment

1.1 HPA (HorizontalPodAutoScale)
StatefulSet
DaemonSet
Job, Cronjob

RelicationController & ReplicaSet & Deployment & HPA (HorizontalPodAutoScale)

ReplicationController 用來確保容器應用的副本數始終保持在用戶定義的副本數，即如果有容器異常退出，會自動創建新的Pod來替代；而如果異常多出來的容器也自動回收。在新版本中Kubernetes中建議使用ReplicaSet來取代ReplicationController

ReplicaSet 與 RC沒有本質區別，只是名字不一樣，並且ReplicaSet 支持集合式的 selector

一般建議使用Deployment來自動管理ReplicaSet，這樣就無需擔心跟其他機制的不兼容問題(比如 ReplicaSet 不支持rolling-update|滾動更新但 Deployment支持)

Horizontal Pod Autoscaling 僅僅適用於 Deployment 和ReplicaSet，在V1版本中僅支持根據 Pod 的 CPU 利用率所擴容，在vlalpha版本，支持根據內存和用戶自定義的 metric 擴容縮。實現彈性伸縮。利用多個Pod分攤cpu的負載，達到降低cpu使用率的效果。

StatefulSet

StatefulSet 是爲了解決有狀態服務的問題(對應 Deployments 和 ReplicaSets 是爲無狀態服務而設計)，其應用場景包括：

穩定的持久化存儲，即 Pod 重新調度後還是能訪問到相同的持久化數據，基於PVC實現
穩定的網絡標誌，即 Pod 重新調度後其 PodName 和 HostName 不變，基於 Headless Service (即沒有 Cluster IP 的 Service ) 來實現
有序部署，有序擴展，即Pod是有順序的，在部署或者擴展的時候要根據定義的順序依次進行(即從 0 到 N-1，在下一個 Pod 運行之前所有之前的 Pod 必須都是 Running 和 Ready 狀態)，基於 init containers 來實現。
有序收縮，有序刪除 (即從 N-1 到 0)

DaemonSet

DaemonSet 確保全部 (或者一些) Node 上運行一個 Pod 的副本。當有 Node 加入集羣時，也會爲他們新增一個 Pod。當有 Node 從集羣移除時，這些 Pod 也會被回收。刪除 DaemonSet 將會刪除它創建的所有 Pod。

使用 DaemonSet 的一些典型用法：

運行集羣存儲 daemon，例如在每個 Node 上運行 glusterd，ceph。
在每個 Node 上運行日誌收集 daemon，例如fluentd，logstash。
在每個 Node 上運行監控 daemon，例如 Prometheus Node Exporter

Job, Cronjob

Job 負責批處理任務，即僅執行一次的任務，它保證批處理任務的一個或多個 Pod 成功結束

Cron Job管理基於時間的 Job，即

在給定時間點只運行一次
週期性地在給定時間點運行

這兩個類似Linux的定時任務，at和crontab的區別，運行一次和運行多次，是否可以複用

網絡通訊方式

Kubernetes 的網絡模型假定了所有 Pod 都在一個可以直接連通的扁平的網絡空間中，這在 GCE(Google Computer Engine) 裏面是現成的網絡模型，Kubernetes 假定這個網絡已經存在。而在私有云裏搭建 Kubernetes 集羣，就不能假定這個網絡已經存在了。我們需要自己實現這個網絡假設，將不同節點上的 Docker 容器之間的互相訪問先打通，然後運行Kubernetes

同一個 Pod 內的多個容器之間：lo(localhost)
各 Pod 之間的通訊：Overlay Network
Pod 與 Service 之間的通訊：各節點的 Iptables 規則，最新版本可以通過LVS

Flannel

Flannel 是 CoreOS 團隊針對 Kubernetes 設計的一個網絡規劃服務，簡單來說，它的功能是讓集羣中的不同節點主機創建的 Docker 容器給都具有全集羣唯一的虛擬IP地址。而且它還能在這些IP地址之間建立一個覆蓋網絡(Overlay Network)，通過這個覆蓋網絡，將數據包原封不動地傳遞到目標容器內。不同機器上運行的docker容器(IP不同，可以通過網橋修改分配IP)。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-dwD4zhfs-1583118152626)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581415395239.png)]

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-JiEr9ynZ-1583118152627)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581415437865.png)]

ETCD 和 Flannel 之間的關聯

存儲管理 Flannel 可分配的 IP 地址段資源
監控 ETCD 中每個 Pod 的實際地址，並在內存中建立維護 Pod 節點路由表

ETCD擁有非常優秀的集羣化

不同情況下網絡通信方式

同一個Pod內部通訊：同一個Pod共享同一個網絡命名空間，共享同一個Linux協議棧

Pod1 至 Pod2

Pod1 與 Pod2不在同一臺主機，Pod的地址是與docker0在同一個網段的，但docker0網段與宿主機網卡是兩個完全不同的IP網段，並且不同Node之間的通信只能通過宿主機的物理網卡進行。將Pod的IP和所在Node的IP關聯起來，通過這個關聯讓Pod可以互相訪問。
Pod1 與 Pod2 在同一臺機器，由docker0網橋直接轉發請求至 Pod2，不需要經過 Flannel

Pod 至 Service 的網絡：目前基於性能考慮，全部爲iptables 維護和轉發| 最新版本，可以通過LVS維護和轉發

Pod 到外網：Pod 向外網發送請求，查找路由表，轉發數據包到宿主機的網卡，宿主網卡完成路由選擇後，iptables執行Masquerade，把源IP更改爲宿主網卡的IP，然後向外網服務器發送請求。

外網訪問 Pod : Service

組件通訊示意圖

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-DBB7mDv2-1583118152627)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581423162201.png)]

LVS

Service和Pod如何及建立聯繫/服務發現

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-7XSYl1dE-1583118152627)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581413907960.png)]

通過類似CSS選擇器的功能。每個Pod都會有一個Label標籤，比如MySQL的標籤 name=mysql，運行php的標籤 name=php。Service通過這些標籤，就知道和對應的Pod建立聯繫了

APISERVER

相當於一個交通中心

Node

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-HY2knY7a-1583118152628)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581409191224.png)]

需要安裝 kubelet，kube-proxy，Docker/虛擬機

kubelet

作用：CRI(Container Runtime Interface)

直接跟容器引擎交互實現容器的生命週期

kube-proxy

實現Pod與Pod之間的訪問，實現負載均衡。
操作對象爲防火牆，去實現Pod的映射
支持IPVS(LVS)

Replication Controller(RC)

副本控制器。維護副本數(達到期望的量)

Scheduler

調度器，複製介紹任務，選擇合適的節點進行分配任務

Etcd

ETCD內部架構圖

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-psfqZ2iW-1583118152628)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\1581408991826.png)]

採用go語言編寫的鍵值對數據庫

etcd官方將它定位成一個可信賴的分佈式鍵值對存儲服務，它能夠爲整個分佈式集羣存儲一些關鍵數據，協助分佈式集羣的正常運轉。

etcd屬於分佈式一致性k-v數據庫，一般用於保存配置信息等

天生具有集羣化特性。

v2

需要備份

v3

最新版本，數據存在磁盤當中。

CoreDNS

可以爲集羣中的SVC創建一個域名IP的對應關係解析，是實現負載均衡的其中一個組件

Dashboard

給 K8S 集羣提供一個 B/S 結構訪問體系

B/S結構

B/S (Browser/Server)：又稱瀏覽器/服務器模式。這種模式統一了客戶端，將系統功能實現的核心部分集中到服務器上，簡化了系統的開發、維護和使用。客戶機上只要安裝一個瀏覽器，如Internet Explorer，服務器安裝SQL Server、Oracle、MYSQL等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。

C/S結構

C/S(Client/Server)：又稱客戶/服務器模式。服務器通常採用高性能的PC、工作站或小型機，並採用大型數據庫系統，如Oracle、Sql Server等。客戶端需要安裝專用的客戶端軟件。

B/S vs C/S

一、C/S
1.優點：
（1）安全性：需要其特定的客戶端，所以面向對象比較確定，將所進行的信息安全處於一個可控的範圍
（2）效率：客戶端的服務器直接相連，省卻了中間環節，數據的傳輸比較快
（3）個性化：有特定的客戶端，所以可以在較大程度上滿足客戶的個性化要求
（4）穩定性：結構比較穩定，有較強的事務處理能力，可以實現較複雜的業務邏輯
2.缺點：
（1）特定的客戶端：對pc機有一定的要求，如：操作系統，並且它就像訂在牆上的石頭桌子，不可再利用
（2）中間環節：因爲省卻了中間環節，所以當客戶端達到一定的量時，同時訪問服務器，造成服務器的相應變慢，效率變低

二、B/S
1.優點：
（1）範圍：零安裝，擁有一個瀏覽器，即可訪問，面向的範圍更廣
（2）維護性：維護簡單，更新頁面，即可實現面向所有用戶的更新
（3）共享性：通過瀏覽器訪問，共享性強，就像買來的餐桌，可以再利用
2.缺點：
（1）安全性：面向的範圍廣，所以安全性比較低
（2）個性化：因爲面型的範圍廣，所以它是一種公共審美，無法滿足個性化的需求

Ingress Controller

官方只能實現四層代理，Ingress可以實現七層代理

Federation

提供一個可以跨集羣中心多K8S統一管理功能

Prometheus

提供K8S集羣的監控能力

ELK

提供K8S集羣日誌統一分析介入平臺

安裝/下載

構建軟路由

雲原生

文章中所有的圖片來源自互聯網，如侵請聯繫作者刪除

koolshare配置

安裝好koolshare後

目的

實現3個機器以內網訪問koolshare，通過koolshare訪問外網。

centos7的ip配置在

/etc/sysconfig/network-scripts/ifcfg-ens33

TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=static
# 改爲靜態static
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=ens33
UUID=d0e94d00-aeaa-4f88-b79a-8501e330662e
DEVICE=ens33
ONBOOT=yes
IPADDR=192.168.66.10
# 配置該機器的ip
NETMASK=255.255.255.0
# 掩網
GATEWAY=192.168.66.1
# 網關
DNS1=192.168.66.1
DNS2=114.114.114.114

技術小白的Kubernetes學習自白