k8s單節點搭建一台伺服器

⑴ 搭建k8s有哪些方式

• #啟動etcd

• sudodockerrun-d--net=host--name=etcd1-v/etc/kubernetes/ssl:/etc/kubernetes/ssl-v/var/etcd/data/:/var/etcd/data/gcr.io/google_containers/etcd:3.0.17/usr/local/bin/etcd--data-dir=/var/etcd/data

• --name=etcd2

• --listen-client-urls=http://0.0.0.0:2379

• --advertise-client-urls=http://192.168.56.103:2379

• --initial-advertise-peer-urls=http://192.168.56.103:2380

• --listen-peer-urls=http://192.168.56.103:2380

• --initial-cluster=etcd0=http://192.168.56.101:2380,etcd1=http://192.168.56.102:2380,etcd2=http://192.168.56.103:2380

• --initial-cluster-state=new

• --cert-file=/etc/kubernetes/ssl/kubernetes.pem

• --key-file=/etc/kubernetes/ssl/kubernetes-key.pem

• --peer-cert-file=/etc/kubernetes/ssl/kubernetes.pem

• --peer-key-file=/etc/kubernetes/ssl/kubernetes-key.pem

• --trusted-ca-file=/etc/kubernetes/ssl/ca.pem

• --peer-trusted-ca-file=/etc/kubernetes/ssl/ca.pem

• --initial-cluster-tokenetcd-cluster-0

• sudodockerrun-d--net=host--name=etcd0-v/etc/kubernetes/ssl:/etc/kubernetes/ssl-v/var/etcd/data/:/var/etcd/data/gcr.io/google_containers/etcd:3.0.17/usr/local/bin/etcd--data-dir=/var/etcd/data--name=etcd0

• --listen-client-urls=http://0.0.0.0:2379--advertise-client-urls=http://0.0.0.0:2379

• --initial-cluster-state=new

• --cert-file=/etc/kubernetes/ssl/kubernetes.pem

• --key-file=/etc/kubernetes/ssl/kubernetes-key.pem

• --peer-cert-file=/etc/kubernetes/ssl/kubernetes.pem

• --peer-key-file=/etc/kubernetes/ssl/kubernetes-key.pem

• --trusted-ca-file=/etc/kubernetes/ssl/ca.pem

• --peer-trusted-ca-file=/etc/kubernetes/ssl/ca.pem

• #驗證

• http://10.101.85.159:2379/v2/members

• etcdctl--ca-file=/etc/kubernetes/ssl/ca.pem

• --cert-file=/etc/kubernetes/ssl/kubernetes.pem

• --key-file=/etc/kubernetes/ssl/kubernetes-key.pem

• cluster-health

• #啟動api

• sudodockerrun-d--net=host--name=kube-apiserver-v/etc/kubernetes:/etc/kubernetesgcr.io/google_containers/hyperkube:v1.6.1/hyperkubeapiserver

• --service-cluster-ip-range=10.254.0.0/16

• --advertise-address=192.168.56.101--bind-address=192.168.56.101--insecure-bind-address=192.168.56.101

• --kubelet-port=10250

• --port=8080

• --allow-privileged=true

• --admission-control=ServiceAccount,NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQuota

• --authorization-mode=RBAC

• --runtime-config=rbac.authorization.k8s.io/v1beta1

• --kubelet-https=true

• --experimental-bootstrap-token-auth

• --token-auth-file=/etc/kubernetes/token.csv

• --service-node-port-range=30000-32767

• --tls-cert-file=/etc/kubernetes/ssl/kubernetes.pem

• --tls-private-key-file=/etc/kubernetes/ssl/kubernetes-key.pem

• --client-ca-file=/etc/kubernetes/ssl/ca.pem

• --service-account-key-file=/etc/kubernetes/ssl/ca-key.pem

• --v=0

• --logtostderr=true

• --allow-privileged=true

• --etcd-cafile=/etc/kubernetes/ssl/ca.pem

• --etcd-certfile=/etc/kubernetes/ssl/kubernetes.pem

• --etcd-keyfile=/etc/kubernetes/ssl/kubernetes-key.pem

• --etcd-servers=http://192.168.56.101:2379,http://192.168.56.102:2379,http://192.168.56.103:2379

• --audit-log-maxage=30--audit-log-maxbackup=3--audit-log-maxsize=100--event-ttl=1h

• #kube-controller-manager

• sudodockerrun-d--net=host--name=kube-controller-manager-v/etc/kubernetes:/etc/kubernetesgcr.io/google_containers/hyperkube:v1.6.1/hyperkubecontroller-manager

• --master=http://192.168.56.101:8080

• --service-cluster-ip-range=10.254.0.0/16

• --cluster-signing-cert-file=/etc/kubernetes/ssl/ca.pem

• --cluster-signing-key-file=/etc/kubernetes/ssl/ca-key.pem

• --service-account-private-key-file=/etc/kubernetes/ssl/ca-key.pem

• --root-ca-file=/etc/kubernetes/ssl/ca.pem

• --v=2--leader-elect=true

• #scheler

• sudodockerrun-d--net=host--name=kube-scheler-v/etc/kubernetes:/etc/kubernetesgcr.io/google_containers/hyperkube:v1.6.1/hyperkubescheler

• --master=http://192.168.56.101:8080

• --v=2--leader-elect=true

• FLANNEL_NETWORK=192.168.0.0/16

• FLANNEL_SUBNET=192.168.40.1/24

• FLANNEL_MTU=1450

• FLANNEL_IPMASQ=false

• etcdctl--ca-file=/etc/kubernetes/ssl/ca.pem

• --cert-file=/etc/kubernetes/ssl/kubernetes.pem

• --key-file=/etc/kubernetes/ssl/kubernetes-key.pem

• set/coreos.com/network/config"{"Network":"10.254.0.0/16","Backend":{"Type":"vxlan"}}"

• etcdctl--ca-file=/etc/kubernetes/ssl/ca.pem

• --cert-file=/etc/kubernetes/ssl/kubernetes.pem

• --key-file=/etc/kubernetes/ssl/kubernetes-key.pem

• get/coreos.com/network/config

• #網路配置

• ./flanneld--etcd-endpoints=http://192.168.56.101:2379,http://192.168.56.102:2379,http://192.168.56.103:2379-etcd-cafile=/etc/kubernetes/ssl/ca.pem-etcd-certfile=/etc/kubernetes/ssl/kubernetes.pem-etcd-keyfile=/etc/kubernetes/ssl/kubernetes-key.pem>/var/log/flanneld2>&1&

• ./mk-docker-opts.sh-i

• cat/run/flannel/subnet.env

• source/run/flannel/subnet.env

• ifconfigdocker0${FLANNEL_SUBNET}

• SUBNET=10.254.0.0/16

• defaultgw=`route-n|grep'^0.0.0.0'|awk'{print$2}'`

• iproutedel$SUBNETvia$defaultgwdeveth0

• iprouteadd$SUBNETvia0.0.0.0devflannel.1

• 10.254.51.0/24

• /etc/systemd/system/multi-user.target.wants/docker.service

• --disable-legacy-registry--bip=192.168.35.1/24--ip-masq=false--mtu=1450

• sudosystemctldaemon-reload

• sudosystemctlrestartdocker

• #

• -bootstrap

• --server=http://192.168.56.101:8080

• --clusterrole=system:node-bootstrapper

• --user=kubelet-bootstrap

• #啟動

• hyperkubekubelet--api-servers=http://192.168.56.101:8080

• --cluster-dns=10.254.0.2

• --cluster-domain=cluster.local.

• --experimental-bootstrap-kubeconfig=/etc/kubernetes/bootstrap.kubeconfig

• --kubeconfig=/etc/kubernetes/kubelet.kubeconfig

• --require-kubeconfig--cert-dir=/etc/kubernetes/ssl>/var/log/kubelet2>&1&

• #apiserver讓其認證通過

• kubectlgetcsr

• kubectlcertificateapprovecsr-2b308

• kubectlgetnodes

• #

• hyperkubeproxy--master=http://192.168.56.101:8080

• --kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig--cluster-cidr=10.254.0.0/16>/var/log/proxy2>&1&

⑵ k8s 基本使用（上）

本文將介紹 k8s 中的一些最基本的命令，並輔以解釋一些基本概念來方便理解，也就是說，本文是一篇偏向實用性而非學術性的文章，如果你想提前了解一下 k8s 相關的知識的話，可以通過以下鏈接進行學習：

k8s 是經典的一對多模型，有一個主要的管理節點 master 和許多的工作節點 slaver 。當然，k8s 也可以配置多個管理節點，擁有兩個以上的管理節點被稱為 高可用 。k8s 包括了許多的組件，每個組件都是單運行在一個 docker 容器中，然後通過自己規劃的虛擬網路相互訪問。你可以通過 kubectl get pod -n kube-system 查看所有節點上的組件容器。

在管理節點中會比工作節點運行更多的 k8s 組件，我們就是靠著這些多出來的組件來對工作節點發號施令。他們都叫什麼這里就不詳細提了。反正對於」基本使用「來說，這些名字並不重要。

要想理解一個東西就要先明白它的內在理念。通俗點就是，k8s 做了什麼？為了提供更加可靠的服務，就要增加伺服器的數量，減少每個伺服器的體量來平攤負載，而越來越多的虛擬機就會帶來越來越高的運維成本。如何讓少量的運維人員就可以管理數量眾多的伺服器及其上的服務呢？這就是 k8s 做的工作。

k8s 把數量眾多的伺服器重新抽象為一個統一的資源池 ，對於運維人員來說，他們面前沒有伺服器1、伺服器2的概念，而是一個統一的資源池，增加新的伺服器對運維人員來說，只是增加自資源池的可用量。不僅如此，k8s 把所有能用的東西都抽象成了資源的概念，從而提供了一套更統一，更簡潔的管理方式。

接下來，我會把每個基本命令當做一節來進行介紹，並輔以介紹一些基本概念。本文介紹的命令涵蓋了增刪改查四方面，可參加下面表格，因為篇幅較長，我們將 create 及之後的不那麼常用的命令放在下一篇文章 k8s 基本使用（下） 里講：

接下來進入正題，首先來了解一下 k8s 中最最最常用的命令 kubectl get ，要記住，k8s 把所有的東西都抽象成了資源，而 kubectl get 就是用來查看這些資源的。最常見的資源就是 pod 。

不僅我們自己的服務是要包裝成 pod 的，就連 k8s 自己也是運行在一堆 pod 上。接下來就讓我們查看一下 k8s 的 pod ：

-n 參數指定了要查看哪個命名空間下的 pod 。 k8s 所有的 pod 都被放置在 kube-system 命名空間下。

執行了 kubectl get pod -n kube-system 命令後，你就可以看到如下內容：

其中每一行就是一個資源，這里我們看到的資源是 pod 。你看到的 pod 數量可能和我的不一致，因為這個列表裡包含了 k8s 在所有節點上運行的 pod ，你加入的節點越多，那麼顯示的 pod 也就越多。我們來一列一列的看：

kubectl get 可以列出 k8s 中所有資源

這里只介紹了如何用 kubectl 獲取 pod 的列表。但是不要把 get 和 pod 綁定在一起，pod 只是 k8s 中的一種服務，你不僅可以 get pod ，還可以 get svc ( 查看服務 )、 get rs ( 查看副本控制器 )、 get deploy ( 查看部署 )等等等等，雖然說 kubectl get pod 是最常用的一個，但是如果想查看某個資源而又不知道命令是什麼， kbuectl get <資源名> 就對了。

如果你想看更多的信息，就可以指定 -o wide 參數，如下：

加上這個參數之後就可以看到資源的所在 ip 和所在節點 node 了。

記得加上 -n

-n 可以說是 kubectl get 命令使用最頻繁的參數了，在正式使用中，我們永遠不會把資源發布在默認命名空間。所以，永遠不要忘記在 get 命令後面加上 -n 。

kubectl get 命令可以列出 k8s 中的資源，而 kubectl get pod 是非常常用的查看 pod 的命令。而 -n 參數則可以指定 pod 所在的命名空間。

kubectl describe 命令可以用來查看某一資源的具體信息，他同樣可以查看所有資源的詳情， 不過最常用的還是查看 pod 的詳情 。他也同樣可以使用 -n 參數指定資源所在的命名空間。

舉個例子，我們可以用下面命令來查看剛才 pod 列表中的某個 pod，注意不要忘記把 pod 名稱修改成自己的：

然後你就可以看到很多的信息，咱們分開說，首先是基本屬性，你可以在詳細信息的開頭找到它：

基本屬性

其中幾個比較常用的，例如 Node 、 labels 和 Controlled By 。通過 Node 你可以快速定位到 pod 所處的機器，從而檢查該機器是否出現問題或宕機等。通過 labels 你可以檢索到該 pod 的大致用途及定位。而通過 Controlled By ，你可以知道該 pod 是由那種 k8s 資源創建的，然後就可以使用 kubectl get <資源名> 來繼續查找問題。例如上文 DaemonSet/kube-flannel-ds-amd64 ，就可以通過 kubectl get DaemonSet -n kube-system 來獲取上一節資源的信息。

內部鏡像信息

在中間部分你可以找到像下面一樣的 Containers 段落。該段落詳細的描述了 pod 中每個 docker 容器的信息，常用的比如 Image 欄位，當 pod 出現 ImagePullBackOff 錯誤的時候就可以查看該欄位確認拉取的什麼鏡像。其他的欄位名都很通俗，直接翻譯即可。

事件

在 describe 查看詳情的時候，最常用的信息獲取處就是這個 Event 段落了，你可以在介紹內容的末尾找到它，如下：

是的，如果你看到上面這樣，沒有任何 Events 的話，就說明該 pod 一切正常。當 pod 的狀態不是 Running 時，這里一定會有或多或少的問題，長得像下面一樣，然後你就可以通過其中的信息分析 pod 出現問題的詳細原因了：

kubectl describe <資源名> <實例名> 可以查看一個資源的詳細信息，最常用的還是比如 kubectl describe pod <pod名> -n <命名空間> 來獲取一個 pod 的基本信息。如果出現問題的話，可以在獲取到的信息的末尾看到 Event 段落，其中記錄著導致 pod 故障的原因。

如果你想查看一個 pod 的具體日誌，就可以通過 kubectl logs <pod名> 來查看。注意，這個只能查看 pod 的日誌。通過添加 -f 參數可以持續查看日誌。例如，查看 kube-system 命名空間中某個 flannel pod 的日誌，注意修改 pod 名稱：

然後就可以看到如下輸出：

如果你發現某個 pod 的服務有問題，但是狀態還是顯示 Running ，就可以使用 kubectl logs 來查看其詳細日誌。

在本篇文章里，我們了解了 k8s 的宗旨和一些基本概念，並知道了最為常用的 get 、 descibe 及 logs 命令，知道了這三條命令之後就幾乎可以從 k8s 中獲取所有常用信息了。接下來的 k8s 基本使用（下） 里，我們會更深一步，來了解 k8s 中如何創建、修改及刪除資源。

⑶ 基於linux自己初步搭建Kubernetes（k8s）集群基礎，詳細教程

k8s官方網站：https://kubernetes.io/zh/，可自行查看相關文檔說明

k8s-master：Ubuntu--192.168.152.100

k8s-node01：Ubuntu--192.168.152.101

k8s-node02：Ubuntu--192.168.152.102

全部已安裝docker，未安裝可根據官方文檔安裝：https://docs.docker.com/get-docker/

1，禁止swap分區

K8s的要求，確保禁止掉swap分區，不禁止，初始化會報錯。

在每個宿主機上執行：

2，確保時區和時間正確

時區設置

3，關閉防火牆和selinux

ubuntu 查看防火牆命令，ufw status可查看狀態，ubuntu20.04默認全部關閉，無需設置。

4，主機名和hosts設置（可選）

非必須，但是為了直觀方便管理，建議設置。

在宿主機分別設置主機名：k8s-master，k8s-node01，k8s-node02

hosts設置

1，更改docker默認驅動為systemd

為防止初始化出現一系列的錯誤，請檢查docker和kubectl驅動是否一致，否則kubectl沒法啟動造成報錯。版本不一樣，docker有些為cgroupfs，而kubectl默認驅動為systemd，所以需要更改docker驅動。

可查看自己docker驅動命令：

更改docker驅動，編輯 /etc/docker/daemon.json (沒有就新建一個），添加如下啟動項參數即可：

重啟docker

需要在每台機器上安裝以下的軟體包：

2，更新 apt 包索引並安裝使用 Kubernetes apt 倉庫所需要的包

安裝軟體包以允許apt通過HTTPS使用存儲庫，已安裝軟體的可以忽略

3，下載公開簽名秘鑰、並添加k8s庫

國外 ：下載 Google Cloud 公開簽名秘鑰：

國內：可以用阿里源即可：

請注意，在命令中，使用的是Ubuntu 16.04 Xenial 版本， 是可用的最新 Kubernetes 存儲庫。所以而非20.04 的focal。

4，更新 apt 包索引，安裝 kubelet、kubeadm 和 kubectl，並鎖定其版本

鎖定版本，防止出現不兼容情況，例如，1.7.0 版本的 kubelet 可以完全兼容 1.8.0 版本的 API 伺服器，反之則不可以。

只需要在master上操作即可。

1，初始化錯誤解決（沒有報錯的可以跳過這條）

錯誤提示1：

原因：kubectl沒法啟動，journalctl -xe查看啟動錯誤信息。

解決方案：k8s建議systemd驅動，所以更改docker驅動即可，編輯 /etc/docker/daemon.json (沒有就新建一個），添加如下啟動項參數即可：

重啟docker和kubectel

錯誤提示2：

原因：初始化生產的文件，重新初始化，需要刪除即可

錯誤提示3：

解決方法：重置配置

2，初始化完成

無報錯，最後出現以下，表示初始化完成，根據提示還需要操作。

根據用戶是root或者普通用戶操作，由於大多環境不會是root用戶，我也是普通用戶，所以選擇普通用戶操作命令：

如果是root用戶，執行以下命令：

初始化完成，用最後的提示命令 kubeadm join.... 在node機器上加入集群即可。

3，主節點pod網路設置

主節點支持網路插件：https://kubernetes.io/zh/docs/concepts/cluster-administration/addons/

這里安裝Calico網路插件：https://docs.projectcalico.org/getting-started/kubernetes/self-managed-onprem/onpremises

Calico官網提供三種安裝方式，1）低於50個節點，2）高於50個節點，3）etcd datastore（官方不建議此方法）。

這里選擇第一種：

安裝完成後， kubectl get node 可查看節點狀態，由NotReady變成Ready則正常，需要等幾分鍾完成。

1，node加入master節點

在所有node節點機器操作，統一已安裝完成 kubelet、kubeadm 和 kubectl，用master初始化完成後最後提示命令加入，切記要用root用戶。

加入成功後，提示如下：

再次查看kubelet服務已正常啟動。

2，需注意的坑

1：加入主節點，需要 root 用戶執行詞條命令，才可以加入master主節點。

node在沒有加入主節點master之前，kubelet服務是沒法啟動的，是正常情況，會報錯如下：

原因是缺失文件，主節點master初始化 `kubeadm init`生成。

node節點是不需要初始化的，所以只需要用root用戶`kubeadm join`加入master即可生成。

2：如果加入提示某些文件已存在，如：

原因是加入過主節點，即使沒成功加入，文件也會創建，所以需要重置節點，重新加入即可，重置命令：

3，在master查看節點

加入完成後，在master節點 kubectl get node 可查看已加入的所有節點：

這里k8s集群創建完成，下一步使用可參考我的下一篇文章：k8s初步熟悉使用介紹，實踐搭建nginx集群

⑷ 如何在Kubernetes中部署一個高可用的Postgresql集群環境

雖然 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內存需要多大

你好！2gb或者4gb都行
1.什麼是k8s？
k8s是一個docker容器管理工具
它是一個全新的基於容器技術的分布式架構領先方案，是開源的容器集群管理系統。
在docker的基礎上，為容器化的應用提供部署運行，資源調度，服務發現和動態伸縮等一系列完整功能
2.----k8s的優勢：
a，容器編排
b，輕量級
c，開源
d，彈性伸縮
e，負載均衡
二：k8s的核心功能
1.自愈: 重新啟動失敗的容器，在節點不可用時，替換和重新調度節點上的容器，對用戶定義的健康檢查不響應的容器會被中止，並且在容器准備好服務之前不會把其向客戶端廣播。
彈性伸縮: 通過監控容器的cpu的負載值,如果這個平均高於80%,增加容器的數量,如果這個平均低於10%,減少容器的數量
服務的自動發現和負載均衡: 不需要修改您的應用程序來使用不熟悉的服務發現機制，Kubernetes 為容器提供了自己的 IP 地址和一組容器的單個 DNS 名稱，並可以在它們之間進行負載均衡。
滾動升級和一鍵回滾: Kubernetes 逐漸部署對應用程序或其配置的更改，同時監視應用程序運行狀況，以確保它不會同時終止所有實例。 如果出現問題，Kubernetes會為您恢復更改，利用日益增長的部署解決方案的生態系統。

⑹ k8s 網路基礎

author：sufei
說明：本文主要記錄在學習k8s網路方面的相關知識

 Linux在內核網路棧中引入網路命名空間，將 獨立的網路協議棧隔離 到不同的命令空間中，彼此間無法通信；

1、Linux操作系統，解析和封裝網路包是通過一個網路協議棧完成，下層為上層服務，這個 協議棧中即包括如軟體也包括硬體網路設 備。網路命名空間就是以軟體方式隔離出單獨的網路棧信息；

2、不同network namespace的軟硬體資源相互不可見，好像處在物理隔離的不同物理機上一樣，彼此隔離；

3、不同的網路命名空間會有自己獨立的網卡、路由表、ARP 表、iptables 等和網路相關的資源

4、實驗：可以藉助 ip netns 命令來完成對 Network Namespace 的各種操作，如：

問題 ：什麼是轉移設備？

 可以在不同的 Network Namespace 之間轉移設備（如veth）。由於一個設備只能屬於一個 Network Namespace ，所以轉移後在這個 Network Namespace 內就看不到這個設備了。 veth設備屬於可轉移設備 ，而很多其它設備（如lo、bridge等）是不可以轉移的。

 veth pair 全稱是 Virtual Ethernet Pair，是一個成對的埠，所有從這對埠一 端進入的數據包都將從另一端出來，反之也是一樣。而veth pair就是為了在不同的 Network Namespace 直接進行通信，利用它可以直接將兩個 Network Namespace 連接起來。

實驗

 veth pair打破了 Network Namespace 的限制，實現了不同 Network Namespace 之間的通信。但veth pair有一個明顯的缺陷，就是只能實現兩個網路介面之間的通信。如果我們想實現多個網路介面之間的通信，就可以使用下面介紹的網橋（Bridge）技術（ 類似於物理交換機 ）。
 簡單來說，網橋就是把一台機器上的若干個網路介面「連接」起來。其結果是，其中一個網口收到的報文會被復制給其他網口並發送出去。以使得網口之間的報文能夠互相轉發。

 網橋是一個二層網路設備，通過網橋可以將linux支持的不同的埠連接起來,並實現類似交換機那樣的多對多的通信。

實驗：

 

 Netfilter負責在內核中執行各種掛接的規則(過濾、修改、丟棄等)，運行在內核 模式中；Iptables模式是在用戶模式下運行的進程，負責協助維護內核中Netfilter的各種規則表；通過二者的配合來實現整個Linux網路協議棧中靈活的數據包處理機制。

 iptables/netfilter(簡稱iptables)組成了Linux平台下的包過濾防火牆，可以完成封包過濾、封包重定向和網路地址轉換（NAT）等功能。這部分主要了解兩部分知識：

 應用層不管是要發送還是接收網路消息，都需要通過linux內核提供的一系列關卡。每個」關卡「擔負著不同的工作。這里的」關卡「被稱為」鏈「。如下圖：

 Docker啟動一個容器時會根據Docker網橋的網段分配給容器一個IP地址，稱為Container-IP，同時Docker網橋是每個容器的默認網關(如上面的172.17.0.1)。因為在同一宿主機內的容器都接入同一個網橋，這樣容器之間就能夠通過容器的Container-IP直接通信。

 Docker網橋是宿主機虛擬出來的，並不是真實存在的網路設備，外部網路是無法定址到的，這也意味著外部網路無法通過直接Container-IP訪問到容器。如果容器希望外部訪問能夠訪問到，可以通過映射容器埠到宿主主機（埠映射），即docker run創建容器時候通過 -p 或 -P 參數來啟用，訪問容器的時候就通過[宿主機IP]:[容器埠]訪問容器。

 下面具體來說說docker容器的幾種網路模式，以便後續學習k8s網路。

 在host模式下（ –net=host），容器不會去建立新的網路命名空間，而直接使用宿主機的網路設備以及網路協議棧。這樣自然不會虛擬出自己的網卡，配置自己的IP等。其特點如下：

 這個模式就是在創建容器時，指定網路（–net=container:NAME_or_ID）與之前容器在同一個網路命名空間中，而不是和宿主機共享（這也就是k8s中pod內各容器的一種網路模式）。下面說明幾點：

 none模式(–net=none)Docker容器擁有自己的Network Namespace，但是，並不為Docker容器進行任何網路配置。也就是說，這個Docker容器沒有網卡、IP、路由等信息。需要我們自己為Docker容器添加網卡、配置IP等。

 bridge模式是docker容器的默認模式，當Docker進程啟動時，會在主機上創建一個名為docker0的虛擬網橋，此主機上啟動的Docker容器在bridge模式下會連接到這個虛擬網橋上，並由網橋自動分配ip。虛擬網橋的工作方式和物理交換機類似，這樣主機上的所有容器就通過交換機連在了一個二層網路中。

 下面說明這個模式下的工作方式：

 首先我們來看看k8s想要一個什麼樣的網路，也就是k8s網路設計的要求，具體如下：

 下面簡單從幾中不同的通信要求來看看k8s網路實現。

 在 Kubernetes 的世界裡，IP 是以 Pod 為單位進行分配的。一個 Pod 內部的所有容器共享一個網路堆棧。實際上就是docker container網路模式。可以直接通過本地localhost進行網路訪問。這個模式在mysql容器化中就是agent容器與mysql容器的網路通信方式。

 Pod1和Pod2都是通信veth pair連接到同一個docker0網橋上，它們的IP地址都是從docker0網段上動態獲取的，它們和網橋本身的IP是同一個網段的。可以通過docker0作為交換機進行通信，也就是採用的docker bridge網路模式進行通信。

 由於在同一個網橋docker0上即可以保證分配的pod IP不會沖突，且可以相互通信，而如果需要跨Node物理節點，則無法通過docker網路直接滿足要求了，那這些要求具體有哪些呢？

解決方案

方法一：k8s中通過在etcd中記錄正在運行中pod的IP分配信息，這樣我們就可以滿足Pod IP與Node IP之間映射關系的記錄；

方法二：可以在etcd中規劃配置好所有主機docker0網橋的子網范圍，從而滿足Pod IP不沖突的要求；如：

方法三：要實現Pod跨Node通信，以k8s默認網路Flannel為例，就是採用overlay（覆蓋網路）實現。具體下面說明：

問題：什麼是覆蓋網路？

覆蓋網路就是應用層網路，是指建立在另一個網路上的網路。怎麼理解呢？簡單理解就是將TCP數據包裝在另一種網路包裡面進行路由轉發和通信，另一種網路包目前可以是UDP、VxLAN、AWS VPC和GCE路由等數據轉發方式。默認以UDP為例來說明flannel工作方式。

下面看看具體實現

問題 ：為保證各node內docker容器分配的ip地址不沖突，每個節點上的Docker會使用不同的IP地址段？如何實現的呢？

問題 ：為什麼在發送節點上的數據會從docker0路由到flannel0虛擬網卡，在目的節點會從flannel0路由到docker0虛擬網卡？

⑺ K8S安裝和創建集群終極教程（單master多worker）

本文會以 最簡單 、 最直接 、 最完整 的方式記錄kubernetes（下面統稱K8S）單master多工作節點（worker nodes）的集群步驟

首先要簡單了解一下本文的3個核心概念：

內存建議至少4G

問：如何查看主機名？

答：執行命令hostname

問：如何修改主機名？

答：永久生效的做法：執行命令vi /etc/hostname，把第一行去掉（不能注釋掉，要去掉），然後重新寫上自定義的主機名（注意命名規范），保存並重啟後生效；

臨時生效的做法：執行以下命令

問：如何查看MAC地址？

答：執行命令ip link，然後看你的第一網卡

問：如何查看proct_uuid？

答：執行命令sudo cat /sys/class/dmi/id/proct_uuid

注意：30000-32767這個埠范圍是我們創建服務的埠必須要設置的一個范圍（如果設置范圍以外的會有限制提示並創建失敗），這是K8S規定的。

另外，如果你要直接關閉防火牆可以執行

⑥必須禁用Swap

Swap total大於0，說明Swap分區是開啟的

問：如何關閉Swap？

答：編輯文件/etc/fstab，在swap行前面加上#號注釋， 保存並重啟伺服器

再次查看分區狀態，已生效

常見的容器引擎（Container runtime，簡稱runtime）：

本文使用的容器引擎是Docker

安裝完成後查看版本：

當出現可能跟Docker引擎相關的奇怪異常時可以嘗試把Docker卸載干凈並重新安裝，但一定要注意鏡像、容器、卷或配置文件這些是否需要備份。

下面記錄卸載Docker引擎的步驟：

①卸載 Docker Engine、CLI 和 Containerd 包：

②主機上的映像、容器、卷或自定義配置文件不會自動刪除。刪除所有鏡像、容器和卷：

③配置文件如果有不合法的字元時會導致啟動失敗，我們需要將其刪除然後重建

此時Docker引擎已卸載干凈

官網用的是谷歌的yum源，因為國內是連不上的，所以這里替換成阿里提供的yum源

①安裝

從安裝信息中可以看到版本號是1.22

Installing:

kubeadm x86_64 1.22.4-0 kubernetes 9.3 M

kubectl x86_64 1.22.4-0 kubernetes 9.7 M

kubelet x86_64 1.22.4-0 kubernetes 20 M

②啟動

這就是一個驅動程序，注意cgroup和cgroupfs不要混淆了

引用官方的一段話

「由於 kubeadm 把 kubelet 視為一個系統服務來管理，所以對基於 kubeadm 的安裝， 我們推薦使用 systemd 驅動，不推薦 cgroupfs 驅動。」

kubeadm默認是使用systemd 驅動，而我們的Docker默認驅動是cgroupfs（docker info可以查看），所以需要將Docker的驅動改成systemd

①編輯Docker配置文件

②重啟Docker服務

再次docker info查看驅動信息已變成了systemd

工作節點（worker nodes）的最小配置就到這里了

①鏡像源參數說明

默認情況下, kubeadm 會從 k8s.gcr.io 倉庫拉取鏡像，國內是拉不了的。官方文檔明確表示允許你使用其他的 imageRepository 來代替 k8s.gcr.io。

--image-repository 你的鏡像倉庫地址

接下來我找了一些國內的鏡像源，並簡單做了下分析

綜合上述統計，我選擇阿里雲的鏡像源

②ip地址范圍參數說明

--pod-network-cidr =192.168.0.0/16

注意:如果192.168.0.0/16已經在您的網路中使用，您必須選擇一個不同的pod網路CIDR，在上面的命令中替換192.168.0.0/16。

集群初始化命令：

因為我用的是演示機器，所以這里把完整的執行信息都貼出來方便查閱，平時工作中一定要注意保護好敏感的信息（我的ip地址范圍是自定義的便於下面的功能演示，另外初次init需要下載鏡像文件，一般需要等幾分鍾）

如上所示，集群初始化成功，此時一定要注意看上面執行結果最後的那部分操作提示，我已用標明了初始化成功後還需要執行的3個步驟

注意：如果init成功後發現參數需要調整，可以執行kubeadm reset，它的作用是盡最大努力恢復kubeadm init 或者 kubeadm join所做的更改。

To start using your cluster, you need to run the following as a regular user:

翻譯：開始使用集群前，如果你是普通用戶（非root），你需要執行以下的命令：

Alternatively, if you are the root user, you can run:

翻譯：或者，如果你使用的是root，你可以執行以下命令：

（注意：export只是臨時生效，意味著每次登錄你都需要執行一次）

網路配置配的就是Pod的網路，我的網路插件選用calico

cidr就是ip地址范圍，如果您使用 pod CIDR 192.168.0.0/16，請跳到下一步。

但本文中使用的pod CIDR是192.100.0.0/16，所以我需要取消對清單中的 CALICO_IPV4POOL_CIDR 變數的注釋，並將其設置為與我選擇的 pod CIDR 相同的值。（注意一定要注意好格式，注意對齊）

可根據需求自定義清單，一般不需要的就直接跳過這步

在所有的工作節點上執行join命令（復制之前初始化成功後返回的加入集群命令到所有的工作節點執行即可）

master上查看所有節點的狀態

到這里集群已經創建完成

最後我再安裝K8S的可視化界面kubernetes-dashboard，方便我們日常使用

①下載yaml文件

②修改yaml文件，新增type和nodePort，使服務能夠被外部訪問

③安裝並查看運行情況

④新建用戶

文件創建完成後保存並apply

⑤獲取Token，用於界面登錄

⑥登錄dashboard

192.168.189.128是我的master伺服器ip，另外要注意必須使用https，並且不能使用ie內核模式

復制⑤生成的token到輸入框，點擊登錄

dashboard安裝配置完成

問：如何在查看資源情況？

答：在master上執行以下命令可查看資源情況（-o wide是顯示更詳細的信息），

①查看所有節點

②查看所有命名空間

③查看命名空間下的pod

④查看所有命名空間的pod

⑤實時查看查看命名空間下的pod運行情況

問：kubeadm join 出現異常[ERROR Port-10250]: Port 10250 is in use，如何解決？

答：這是因為你之前join失敗過了，需要先執行kubeadm reset再重新join

問：虛擬機上測試時網卡突然消失如何解決（題外問題記錄）？

答：

①確認丟失的網卡信息，ens開頭（可選步驟）

ifconfig -a

②執行以下命令解決

問：如何查看K8S版本？

答：kubectl version

問：join命令忘記或者過期了怎麼辦？

答：

生成永不過期的

生成時效24小時的

問：Pod不斷重啟並且無其它報錯信息時怎麼辦？

答：這種情況通常是因為你的集群中只有master，沒有worker節點，master的創建默認是有污點的，即不允許調度新的Pod，如果你需要（當然這並不推薦），就需要刪除 master 上的污點。刪除污點可以執行以下命令，

它應該返回以下內容。

⑻ 什麼是K8S

k8s全稱kubernetes，這個名字大家應該都不陌生，k8s是為容器服務而生的一個可移植容器的編排管理工具，越來越多的公司正在擁抱k8s，並且當前k8s已經主導了雲業務流程，推動了微服務架構等熱門技術的普及和落地，正在如火如荼的發展。想要了解更多，我推薦你去看看時速雲，他們是一家全棧雲原生技術服務提供商，提供雲原生應用及數據平台產品，其中涵蓋容器雲PaaS、DevOps、微服務治理、服務網格、API網關等。大家可以去體驗一下。
希望能給您提供幫助，可以給個大大的贊不。