輕量應用伺服器搭建k8s

① 請問公司起步建立k8s，需要什麼樣的伺服器配置，多少台伺服器每台怎樣的配置要求

伺服器按自己預算買就行，vCenter HA cluster 的建議是最少三台伺服器。這樣可以實現一個host維護或有問題的時候另一台馬上能補上。k8s就在vcenter里用vm實現。 ⌄這樣的好處是以後有需求的話可以隨意增加伺服器到vcenter里擴展cpu或者存儲能力。
藍海大腦水冷工作站具有高性能，高密度、擴展性強等特點。液冷GPU伺服器產品支持1~20塊 GPU卡，還可以選擇。晶元主要採用龍芯、飛騰、申威、海光、英偉達、Intel、AMD。完全定製啊，敲開心。適配多個存儲卡，適用於深度學習訓練及推理、生命科學、醫葯研發、虛擬模擬等場景，覆蓋伺服器、靜音工作站、數據中心等多種產品形態，量身定製，滿足客戶全場景需求。

② 騰訊輕量雲伺服器搭建k8s環境

4C4G機器設置為k8smaster節點，另外一台機器設置為k8snode節點

分別進入兩台的 /ect/hosts 目錄，設置r如下host

由於k8s內部節點之間的通訊使用的是內網ip，我們需要把內網ip的重定向到公網ip上

由於兩台機器是處於公網環境，且k8s節點之間需要通訊，所以需要開放一些埠，埠配置可以直接進到騰訊雲控制台進行配置

以下是官網要求的master節點的埠配置

可以進入騰訊雲伺服器的防火牆配置開放相應埠，埠可以限定來源，只允許node節點(192.168.2.2)訪問

以下是官網要求的node節點的埠配置

同理，也設置node節點的埠

master節點需要安裝

node節點需要安裝

添加安裝源(所有節點)

安裝命令

設置開機啟動

修改docker配置（所有節點）

組件安裝完成後就可以啟動了，首先啟動master節點，然後讓node節點加入master幾點即可。

在master節點使用kubeadm初始化集群

這里需要保存token，token是用於node節點加入maste節點的憑證

node節點加入master節點

安裝網路插件，否則node是NotReady狀態（主節點跑）

kubectl get nodes

③ 企業級k8s集群部署

二進制包

註：推薦用二進制包部署Kubernetes集群，雖手動部署麻煩，但可以學習很多工作原理利於後期維護。

環境

可以使用VMware虛擬機，宿主機必須8G內存以上

• 伺服器可以訪問外網，有從網上拉取鏡像的需求

單Master伺服器規劃：（ 註：部署時候根據具體環境進行IP地址調整即可 ）

這里使用3台組建集群，可容忍1台機器故障，當然，你也可以使用5台組建集群

etcd1： 192.168.3.110 etcd2： 192.168.3.112 etcd3： 192.168.3.113

cfssl是一個開源的證書管理工具，使用json文件生成證書，相比openssl更方便使用。

找任意一台伺服器操作，這里用Master節點。

創建工作目錄：

自簽CA：

生成證書：

會生成ca.pem和ca-key.pem文件。

創建證書申請文件：

註：上述文件hosts欄位中IP為所有etcd節點的集群內部通信IP，一個都不能少！為了方便後期擴容可以多寫幾個預留的IP。

生成證書：

會生成etcd.pem和etcd-key.pem文件。

https://github.com/etcd-io/etcd/releases/download/v3.5.1/ etcd-v3.5.1-linux-amd64.tar.gz

以下在節點1上操作，然後將文件拷貝到其他集群機器

把剛才生成的證書拷貝到配置文件中的路徑：

注意修改節點2和節點3分別etcd.conf配置，按照下面提示的修改

啟動各節點的etcd服務

如果輸出上面信息，就說明集群部署成功。

如果有問題看日誌：/var/log/message

docker二進制下載地址：

https://download.docker.com/linux/static/stable/x86_64/docker-19.03.9.tgz

註：使用yum安裝也行

集群所有機器都安裝docker

生成證書：

會生成ca.pem和ca-key.pem文件。

創建證書申請文件：

生成證書：

會生成k8s.pem和k8s-key.pem文件。

下載地址參考：

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#downloads-for-v12013

Wget https://dl.k8s.io/v1.20.13/kubernetes-server-linux-amd64.tar.gz

把剛才生成的證書拷貝到配置文件中的路徑：

TLS Bootstrapping 機制，對work-node加入進行自簽證書用

創建上述配置文件中token文件：

token 可以自行生產，網路下怎麼生產

kube-apiserver服務

生成kube-controller-manager證書：

生成kubeconfig文件（以下是shell命令，直接在終端執行）：

生成kube-scheler證書：

生成kubeconfig文件：

生成kubeconfig文件：

通過kubectl工具查看當前集群組件狀態：

在所有worker node創建工作目錄：

從master節點拷貝：

註：由於網路插件還沒有部署，節點會沒有準備就緒 NotReady

二進制包下載地址：https://github.com/containernetworking/plugins/releases

確保kubelet啟用CNI：

在Master執行：

應用場景：例如kubectl logs

在Master節點將Worker Node涉及文件拷貝到新節點192.168.3.112/113

註：這幾個文件是證書申請審批後自動生成的，每個Node不同，必須刪除

Node2（192.168.3.113 ）節點同上。記得修改主機名！

訪問地址：https://NodeIP:30001

創建service account並綁定默認cluster-admin管理員集群角色：

使用輸出的token登錄Dashboard。

CoreDNS用於集群內部Service名稱解析。

DNS解析測試：

這樣 單Master集群就搭建完成了

④ 如何在本地快速啟動一個k8s集群小技巧，學到了

最近在閱讀《每天5分鍾玩轉Kubernetes》 這本書，個人感覺是一本不錯的 K8S 的入門書籍。

我們在剛開始學習一項技術的時候，不論是通過官方文檔、書籍，亦或是視頻的形式，如果僅僅是去看，而不去練習實踐的話，那麼是很難將其真正應用起來的。

然而當我開始准備實踐的時候，發現要想在本地將 K8S 跑起來，並不像我們想像的那麼容易。存在以下幾點「問題」：

那麼有沒有什麼方案可以更優雅更輕量更快速搭建一個 K8S 集群呢？答案就是 k3d。

其實有很多種方式可以在本地運行 k8s，比如：

當然了，如果只是學習 k8s 的使用，那麼以上方案均可以使用。

k3s 包括以下一些組件：

k3s 是一種模塊化的發行版，可以很方便的替換上面的組件。

在 Mac 下，使用 Homebrew 可以很方便的安裝 k3d： brew install k3d。

順手安裝一下 kubectl 和 kubecm：

我們通過 k3d 的命令可以輕易的在本地啟動一個或 N 個 k8s 集群。

首先我們嘗試創建一個 1主2從 的集群：

初次創建可能會比較慢，因為會從 Docker 倉庫拉取最新的 rancher/k3s 鏡像。

當出現下面的日誌時，k8s 集群就創建成功了

此時，我們按照日誌提示，運行 kubectl cluster-info 查看下當前集群的信息：

運行 kubectl get nodes 查看下當前集群的節點情況：

注意，這里的「節點」其實是本機 Docker 運行的容器，通過 docker ps 查看下當前本機運行的容器吧

解釋一下我們創建集群時配置的埠映射：

現在我們集群和主機的網路通信是這樣子的：

創建一個 nginx 的 Deployment

創建一個 Service 通過 ClusterIP 的方式暴露服務

創建一個 Ingress，k3s 默認安裝的是 traefik 1.x 作為 Ingress Controller

此時，打開瀏覽器，訪問 http://localhost:8080/ 就可以看到熟悉的 nginx 默認頁。

這是不是太酷了~

當使用 Helm Chart 安裝 Rancher 時，可能會出現如下錯誤日誌：

要創建一個 k8s 版本號為 v1.19.8-k3s1 的 k8s 集群，可以在創建集群的命令後面加 --image 參數，指定版本號：k3d cluster create first-cluster xxxxx --image rancher/k3s:v1.19.8-k3s1

還記得在第二步順手安裝的 kubecm 嗎？

當我們在本地使用 k3d 創建了多個集群之後，我們可以通過 kubecm 快速切換 context。

⑤ Gitlab+Jenkins+Docker+Harbor+K8s集群搭建CICD平台

上帝藉由各種途徑使人變得孤獨，好讓我們可以走向自己。 ——赫爾曼·黑塞《德米安》

CI即為 持續集成(Continue Integration,簡稱CI) ，用通俗的話講，就是 持續的整合版本庫代碼編譯後製作應用鏡像 。建立有效的持續集成環境可以減少開發過程中一些不必要的問題、 提高代碼質量、快速迭代 等,

Jenkins :基於Java開發的一種持續集成工具,用於監控持續重復的工作,旨在提供一個開放易用的軟體平台,使軟體的持續集成變成可能。
Bamboo : 是一個企業級商用軟體,可以部署在大規模生產環境中。

CD即持續交付Continuous Delivery和持續部署Continuous Deployment，用通俗的話說，即可以持續的部署到生產環境給客戶使用，這里分為兩個階段，持續交付我理解為滿足上線條件的過程，但是沒有上線，持續部署，即為上線應用的過程

關於 CD環境 ，我們使用以前搭建好的 K8s集群 ，K8s集群可以實現應用的 健康 檢測，動態擴容，滾動更新 等優點，關於K8s集群的搭建，小夥伴可以看看我的其他文章

拉取鏡像，啟動並設置開機自啟

配置docker加速器

GitLab 不多介紹。一個基於Git的版本控制平台，,提供了Git倉庫管理、代碼審查、問題跟蹤、活動反饋和wiki，當然同時也提供了

切記:這里的埠要設置成80，要不push項目會提示沒有報錯，如果宿主機埠被佔用，需要把這個埠騰出來

external_url 'http://192.168.26.55』

gitlab_rails[『gitlab_ssh_host』] = 餘.168.26.55』

gitlab_rails[gitlab_shell_ssh_port] = 222

修改完配置文件之後。直接啟動容器

相關的git命令

下面我們要配置私有的docker鏡像倉庫，用到的機器為：

這里倉庫我們選擇 harbor ，因為有web頁面，當然也可以使用 registry

首先需要設置selinux、防火牆

安裝並啟動docker並安裝docker-compose，關於docker-compose，這里不用了解太多，一個輕量的docker編排工具

解壓harbor 安裝包：harbor-offline-installer-v2.0.6.tgz，導入相關鏡像

修改配置文件

harbor.yml：設置IP和用戶名密碼

./prepare && ./install.sh

查看相關的鏡像

訪問測試

這里因為我們要在192.168.26.55(CI伺服器)上push鏡像到192.168.26.56(私倉)，所有需要修改CI伺服器上的Docker配置。添加倉庫地址

修改後的配置文件

載入使其生效

CI機器簡單測試一下

push一個鏡像，可以在私倉的web頁面查看

鏡像jenkins拉取

這里為什麼要改成 1000，是因為容器里是以 jenkins 用戶的身份去讀寫數據，而在容器里jenkins 的 uid 是 1000，

更換國內清華大學鏡像,Jenkins下載插件特別慢，更換國內的清華源的鏡像地址會快不少

"http://www.google.com/" 替換為 "http://www..com/"

替換後查看

重啟docker，獲取登錄密匙

需要修改jenkins綁定的docker的啟動參數 ， ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2376 -H fd:// --containerd=/run/containerd/containerd.sock

修改鏡像庫啟動參數後需要重啟docker

後面 gitlab 要和 jenkins 進行聯動，所以必須要需要對 jenkins 的安全做一些設置，依次點擊 系統管理-全局安全配置-授權策略，勾選"匿名用戶具有可讀許可權"

添加 JVM 運行參數 -Dhudson.security.csrf..DISABLE_CSRF_PROTECTION=true 運行跨站請求訪問

這里的話我們要通過jenkins上的kubectl客戶端連接k8s,所以我們需要安裝一個k8s的客戶端kubectl，下載k8s客戶端

然後拷貝kubeconfig 證書,k8s集群中查看證書位置,這里的證書是之前創建好的,小夥伴可以看看我之前的文章

命令測試沒有問題

我們要部署 Nginx 來運行 hexo 博客系統， hexo 編譯完後為一堆靜態文件，所以我們需要創建一個 svc 和一個 deploy ，使用 SVC 提供服務，使用 deploy 提供服務能力,使用 Nginx+hexo的靜態文件 構成的鏡像

這里我們先用一個Nginx鏡像來代替hexo博客的鏡像

查看deployments和pod

訪問測試沒有問題，之後我們配置好jenkins上的觸發器，直接替換就OK

我們通過 kubectl set 命令更新 deploy 的鏡像時，獲取的鏡像是通過私倉獲取的，所以需要在啟動參數添加私倉地址

這里所有的節點都需要設置後重啟docker

訪問jenkins，接下來才是重點，我們要的jenkins上配置整個CICD流程，從而實現自動化

下面我們編譯一下hexo，生成public的一個文件夾,然後上傳gitlab

同時需要編寫Dockerfile文件來創建鏡像

⑥ 伺服器搭建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會為您恢復更改，利用日益增長的部署解決方案的生態系統。

⑦ Kubernetes（K8S）入門與安裝配置

Kubernetes是一個跨主機集群的開源的容器調度平台，它可以自動化應用容器的部署、擴展和操作,提供以容器為中心的基礎架構。谷歌旗下開源軟體，江湖人稱K8S。

上圖是一個通過K8S搭建的集群環境，採用三台物理機搭建(三台機器是K8S搭建集群的最低要求)，我先簡單介紹一下幾個重點名詞。

Centos7Master*1(注意必須是雙核以上的CPU，否則無法初始化K8S)

Centos7Node*2

將文件上傳至該目錄

網盤地址：https://pan..com/s/1NiAdf0Gp24qjVx2v_HqqyQ

提取碼：aew7

執行以下命令

如果不是groupfs,執行下列語句

將最後一行注釋

運行dockerimages可以看到以下幾個關鍵應用

kube-proxy容器間通訊代理、kube-apiserverAPI服務端、kube-scheler任務調度器、kube-controller-manager集群控制器、corednsK8S內置的DNS伺服器、etcd用於保存集群所有的網路配置和對象的狀態信息、pause前面已經提到用於容器間的通訊以及數據卷的掛載。至此K8S安裝完成

圖中的第一個紅框的命令是需要管理員手動復制，然後在master伺服器上執行的。

PS:admin.conf是kubeadm集群管理的核心配置文件，包含整個集群各個節點的授權信息，以及本身的一些配置信息

第二個紅框中的命令是在node節點上執行，裡麵包含了一個加入集群的token認證信息以及ca證書的hashcode。通過該token可以加入K8S集群.

從圖中看到master節點處於NotReady狀態，說明節點中存在有問題的Pod，查看存在問題的pod，執行以下命令查看所有Pod狀態

如果某個Pod的STATUS處於CrashLoopBackOff狀態表示創建失敗了，那麼它會不斷自動重新創建。上圖中兩個coredns處於pending狀態，原因是我們沒有配置K8S網路通訊協議fannel，從上傳的文件中載入並創建flannel網路組件

3.在node節點上執行剛剛由kubeadm生成的節點加入命令

如果出現反復無法加入節點的情況，運行kubeadmreset這條命令還原當前節點上kubeadminit或者kubeadmjoin所做的所有更改。當想加入新節點忘記token時可以使用kubeadmtokenlist查看token，或者kubeadmtokencreate創建token,採用跳過ca安全認證的方式加入節點。

4.三台機器設置kubelet開機自啟,至此通過kubeadm集群配置完成

在主節點上執行以下命令，以下三個配件都是已經配置好的，裝載即可。

圖中dashboard服務已經被創建，配置文件中關閉了密碼驗證，只需要瀏覽器打開http://192.168.220.131:32000無需登錄。

⑧ 通過K8S部署對象存儲MinIO

MinIO 是全球領先的對象存儲先鋒，以 Apache License v2.0 發布的對象存儲伺服器，是為雲應用和虛擬機而設計的分布式對象存儲伺服器。在標准硬體上，讀/寫速度上高達183GB/s和171GB/s。它與 Amazon S3 雲存儲服務兼容。 它最適用於存儲非結構化數據，如照片、視頻、日誌文件、備份和容器/虛擬機映像。 對象的大小可以從幾KB 到最大5TB。

MinIO是一個非常輕量的服務,可以很簡單的和其他應用的結合，類似 NodeJS, Redis 或者 MySQL。

MinIO支持多種靈活的部署方式，支持Docker Compose、Docker Swam、Kubernetes等，詳見官網： https://docs.min.io/docs/minio-deployment-quickstart-guide.html 或者 https://min.io/download#/linux

這里著重介紹K8S下部署

1、standalone模式

由於service採用NodePort類型，通過主機IP:32593訪問web

2、distributed模式

分布式部署，實例數至少4個，所以需要另外創建4個pv

⑨ 整合k8s系列-02 伺服器端應用

適用版本: Kubernetes v1.22 [stable]

一個完整描述的目標並不是一個完整的對象，僅包括能體現用戶意圖的欄位和值。 該目標（intent）可以用來創建一個新對象， 也可以通過伺服器來實現與現有對象的合並。

系統支持多個應用者（appliers）在同一個對象上開展協作。

「欄位管理（field management）」機制追蹤對象欄位的變化。 當一個欄位值改變時，其所有權從當前管理器（manager）轉移到施加變更的管理器。 當嘗試將新配置應用到一個對象時，如果欄位有不同的值，且由其他管理器管理， 將會引發沖突。 沖突引發警告信號：此操作可能抹掉其他協作者的修改。 沖突可以被刻意忽略，這種情況下，值將會被改寫，所有權也會發生轉移。

當你從配置文件中刪除一個欄位，然後應用這個配置文件， 這將觸發服務端應用檢查此欄位是否還被其他欄位管理器擁有。 如果沒有，那就從活動對象中刪除該欄位；如果有，那就重置為默認值。 該規則同樣適用於 list 或 map 項目。

伺服器端應用既是原有 kubectl apply 的替代品， 也是控制器發布自身變化的一個簡化機制。

如果你啟用了伺服器端應用，控制平面就會跟蹤被所有新創建對象管理的欄位。

用戶管理欄位這件事，在伺服器端應用的場景中，意味著用戶依賴並期望欄位的值不要改變。 最後一次對欄位值做出斷言的用戶將被記錄到當前欄位管理器。 這可以通過發送 POST、 PUT、 或非應用（non-apply）方式的 PATCH 等命令來修改欄位值的方式實現， 或通過把欄位放在配置文件中，然後發送到伺服器端應用的服務端點的方式實現。 當使用伺服器端應用，嘗試著去改變一個被其他人管理的欄位， 會導致請求被拒絕（在沒有設置強制執行時，參見沖突）。

如果兩個或以上的應用者均把同一個欄位設置為相同值，他們將共享此欄位的所有權。 後續任何改變共享欄位值的嘗試，不管由那個應用者發起，都會導致沖突。 共享欄位的所有者可以放棄欄位的所有權，這只需從配置文件中刪除該欄位即可。

欄位管理的信息存儲在 managedFields 欄位中，該欄位是對象的 metadata 中的一部分。

伺服器端應用創建對象的簡單示例如下：

上述對象在 metadata.managedFields 中包含了唯一的管理器。 管理器由管理實體自身的基本信息組成，比如操作類型、API 版本、以及它管理的欄位。

Note: 該欄位由 API 伺服器管理，用戶不應該改動它。

不過，執行 Update 操作修改 metadata.managedFields 也是可實現的。 強烈不鼓勵這么做，但當發生如下情況時， 比如 managedFields 進入不一致的狀態（顯然不應該發生這種情況）， 這么做也是一個合理的嘗試。

managedFields 的格式在 API 文檔中描述。

管理器識別出正在修改對象的工作流程（在沖突時尤其有用）, 管理器可以通過修改請求的參數 fieldManager 指定。 雖然 kubectl 默認發往 kubectl 服務端點，但它則請求到應用的服務端點（apply endpoint）。 對於其他的更新，它默認的是從用戶代理計算得來。

此特性涉及兩類操作，分別是 Apply （內容類型為 application/apply-patch+yaml 的 PATCH 請求） 和 Update （所有修改對象的其他操作）。 這兩類操作都會更新欄位 managedFields，但行為表現有一點不同。

Note:

不管你提交的是 JSON 數據還是 YAML 數據， 都要使用 application/apply-patch+yaml 作為 Content-Type 的值。

所有的 JSON 文檔 都是合法的 YAML。

例如，在沖突發生的時候，只有 apply 操作失敗，而 update 則不會。 此外，apply 操作必須通過提供一個 fieldManager 查詢參數來標識自身， 而此查詢參數對於 update 操作則是可選的。 最後，當使用 apply 命令時，你不能在應用中的對象中持有 managedFields。

一個包含多個管理器的對象，示例如下：

在這個例子中， 第二個操作被管理器 kube-controller-manager 以 Update 的方式運行。 此 update 更改 data 欄位的值， 並使得欄位管理器被改為 kube-controller-manager。

如果把 update 操作改為 Apply，那就會因為所有權沖突的原因，導致操作失敗。

由伺服器端應用實現的合並策略，提供了一個總體更穩定的對象生命周期。 伺服器端應用試圖依據負責管理它們的主體來合並欄位，而不是根據值來否決。 這么做是為了多個主體可以更新同一個對象，且不會引起意外的相互干擾。

當用戶發送一個「完整描述的目標」對象到伺服器端應用的服務端點， 伺服器會將它和活動對象做一次合並，如果兩者中有重復定義的值，那就以配置文件的為准。 如果配置文件中的項目集合不是此用戶上一次操作項目的超集， 所有缺少的、沒有其他應用者管理的項目會被刪除。 關於合並時用來做決策的對象規格的更多信息，參見 sigs.k8s.io/structured-merge-diff.

Kubernetes 1.16 和 1.17 中添加了一些標記， 允許 API 開發人員描述由 list、map、和 structs 支持的合並策略。 這些標記可應用到相應類型的對象，在 Go 文件或在 CRD 的 OpenAPI 的模式中定義：

若未指定 listType，API 伺服器將 patchMergeStrategy=merge 標記解釋為 listType=map 並且視對應的 patchMergeKey 標記為 listMapKey 取值。

atomic 列表類型是遞歸的。

這些標記都是用源代碼注釋的方式給出的，不必作為欄位標簽（tag）再重復。

在極少的情況下，CRD 或者內置類型的作者可能希望更改其資源中的某個欄位的 拓撲配置，同時又不提升版本號。 通過升級集群或者更新 CRD 來更改類型的拓撲信息與更新現有對象的結果不同。 變更的類型有兩種：一種是將欄位從 map/set/granular 更改為 atomic， 另一種是做逆向改變。

當 listType、mapType 或 structType 從 map/set/granular 改為 atomic 時，現有對象的整個列表、映射或結構的屬主都會變為這些類型的 元素之一的屬主。這意味著，對這些對象的進一步變更會引發沖突。

當一個列表、映射或結構從 atomic 改為 map/set/granular 之一 時，API 伺服器無法推導這些欄位的新的屬主。因此，當對象的這些欄位 再次被更新時不會引發沖突。出於這一原因，不建議將某類型從 atomic 改為 map/set/granular。

以下面的自定義資源為例：

在 spec.data 從 atomic 改為 granular 之前，manager-one 是 spec.data 欄位及其所包含欄位（key1 和 key2）的屬主。 當對應的 CRD 被更改，使得 spec.data 變為 granular 拓撲時， manager-one 繼續擁有頂層欄位 spec.data（這意味著其他管理者想 刪除名為 data 的映射而不引起沖突是不可能的），但不再擁有 key1 和 key2。因此，其他管理者可以在不引起沖突的情況下更改 或刪除這些欄位。

默認情況下，伺服器端應用把自定義資源看做非結構化數據。 所有的鍵值（keys）就像 struct 的欄位一樣被處理， 所有的 list 被認為是原子性的。

如果自定義資源定義（Custom Resource Definition，CRD）定義了一個 模式， 它包含類似以前「合並策略」章節中定義過的註解， 這些註解將在合並此類型的對象時使用。

控制器的開發人員可以把伺服器端應用作為簡化控制器的更新邏輯的方式。 讀-改-寫 和/或 patch 的主要區別如下所示：

強烈推薦：設置控制器在沖突時強制執行，這是因為沖突發生時，它們沒有其他解決方案或措施。

除了通過沖突解決方案提供的並發控制， 伺服器端應用提供了一些協作方式來將欄位所有權從用戶轉移到控制器。

最好通過例子來說明這一點。 讓我們來看看，在使用 Horizo ntalPodAutoscaler 資源和與之配套的控制器， 且開啟了 Deployment 的自動水平擴展功能之後， 怎麼安全的將 replicas 欄位的所有權從用戶轉移到控制器。

假設用戶定義了 Deployment，且 replicas 欄位已經設置為期望的值：

application/ssa/nginx-deployment.yaml

並且，用戶使用伺服器端應用，像這樣創建 Deployment：

然後，為 Deployment 啟用 HPA，例如：

現在，用戶希望從他們的配置中刪除 replicas，所以他們總是和 HPA 控制器沖突。 然而，這里存在一個竟態： 在 HPA 需要調整 replicas 之前會有一個時間窗口， 如果在 HPA 寫入欄位成為所有者之前，用戶刪除了replicas， 那 API 伺服器就會把 replicas 的值設為 1， 也就是默認值。 這不是用戶希望發生的事情，即使是暫時的。

這里有兩個解決方案：

首先，用戶新定義一個只包含 replicas 欄位的配置文件：

application/ssa/nginx-deployment-replicas-only.yaml

用戶使用名為 handover-to-hpa 的欄位管理器，應用此配置文件。

在此時間點，用戶可以從配置文件中刪除 replicas 。

application/ssa/nginx-deployment-no-replicas.yaml

注意，只要 HPA 控制器為 replicas 設置了一個新值， 該臨時欄位管理器將不再擁有任何欄位，會被自動刪除。 這里不需要執行清理工作。

通過在配置文件中把一個欄位設置為相同的值，用戶可以在他們之間轉移欄位的所有權， 從而共享了欄位的所有權。 當用戶共享了欄位的所有權，任何一個用戶可以從他的配置文件中刪除該欄位， 並應用該變更，從而放棄所有權，並實現了所有權向其他用戶的轉移。

由伺服器端應用實現的沖突檢測和解決方案的一個結果就是， 應用者總是可以在本地狀態中得到最新的欄位值。 如果得不到最新值，下次執行應用操作時就會發生沖突。 解決沖突三個選項的任意一個都會保證：此應用過的配置文件是伺服器上對象欄位的最新子集。

這和客戶端應用（Client Side Apply） 不同，如果有其他用戶覆蓋了此值， 過期的值被留在了應用者本地的配置文件中。 除非用戶更新了特定欄位，此欄位才會准確， 應用者沒有途徑去了解下一次應用操作是否會覆蓋其他用戶的修改。

另一個區別是使用客戶端應用的應用者不能改變他們正在使用的 API 版本，但伺服器端應用支持這個場景。

客戶端應用方式時，用戶使用 kubectl apply 管理資源， 可以通過使用下面標記切換為使用伺服器端應用。

默認情況下，對象的欄位管理從客戶端應用方式遷移到 kubectl 觸發的伺服器端應用時，不會發生沖突。

Caution:

保持註解 last-applied-configuration 是最新的。 從註解能推斷出欄位是由客戶端應用管理的。 任何沒有被客戶端應用管理的欄位將引發沖突。

舉例說明，比如你在客戶端應用之後， 使用 kubectl scale 去更新 replicas 欄位， 可是該欄位並沒有被客戶端應用所擁有， 在執行 kubectl apply --server-side 時就會產生沖突。

此操作以 kubectl 作為欄位管理器來應用到伺服器端應用。 作為例外，可以指定一個不同的、非默認欄位管理器停止的這種行為，如下面的例子所示。 對於 kubectl 觸發的伺服器端應用，默認的欄位管理器是 kubectl。

如果你用 kubectl apply --server-side 管理一個資源， 可以直接用 kubectl apply 命令將其降級為客戶端應用。

降級之所以可行，這是因為 kubectl server-side apply 會保存最新的 last-applied-configuration 註解。

此操作以 kubectl 作為欄位管理器應用到伺服器端應用。 作為例外，可以指定一個不同的、非默認欄位管理器停止這種行為，如下面的例子所示。 對於 kubectl 觸發的伺服器端應用，默認的欄位管理器是 kubectl。

啟用了伺服器端應用特性之後， PATCH 服務端點接受額外的內容類型 application/apply-patch+yaml。 伺服器端應用的用戶就可以把 YAMl 格式的 部分定義對象（partially specified objects）發送到此端點。 當一個配置文件被應用時，它應該包含所有體現你意圖的欄位。

可以從對象中剝離所有 managedField， 實現方法是通過使用 MergePatch、 StrategicMergePatch、 JSONPatch、 Update、以及所有的非應用方式的操作來覆蓋它。 這可以通過用空條目覆蓋 managedFields 欄位的方式實現。以下是兩個示例：

這一操作將用只包含一個空條目的列表覆寫 managedFields， 來實現從對象中整個的去除 managedFields。 注意，只把 managedFields 設置為空列表並不會重置欄位。 這么做是有目的的，所以 managedFields 將永遠不會被與該欄位無關的客戶刪除。

在重置操作結合 managedFields 以外其他欄位更改的場景中， 將導致 managedFields 首先被重置，其他改變被押後處理。 其結果是，應用者取得了同一個請求中所有欄位的所有權。

Caution: 對於不接受資源對象類型的子資源（sub-resources）， 伺服器端應用不能正確地跟蹤其所有權。 如果你對這樣的子資源使用伺服器端應用，變更的欄位將不會被跟蹤。

參考鏈接：

https://kubernetes.io/zh/docs/reference/using-api/server-side-apply/

順便祝大家五一假期愉快，也不要忘記提升自己。

歡迎大家提出不一樣的觀點，我們一起討論，

我是辣個男人，一個運維人。

⑩ 快速上手k8s——minikube最小實現

最近在研究k8s，就來寫一個關於k8s快速上手，並記錄采坑的點。
需要的前置知識點：docker、k8s的一些基本概念，下面這個可能對你有幫助。
https://juejin.im/post/5d1b2a656fb9a07edc0b7058

我們知道，我們可以將項目製作成docker鏡像，然後利用docker去部署我們的項目，這樣可以解決很多伺服器環境所帶來的問題；
但是容器多了，容器與容器之間就需要訪問，之間就需要網路配置等等，從而就有了docker-compose；
但是當我們的服務進行升級，或者服務需要進行調度，擴容等等，這個時候就需要一個大管家來管所有的東西；
這個大管家就是 - Kubernetes

因為k8s的東西太多了，所以學習成本現在越來越高，好在k8s已經很多教程。我說一下現在學的時候肯定會遇到的大問題：

現在我們就來在本機實現一個最小的k8s的實現，給出一個hello-world
k8s提供了minikube，這個東西可以讓你本機一台機器就可以搭建起這個環境。擁有和線上一樣的命令行操作和模式，但是不需要你再去創建很多虛擬機來搞事情了。超級方便也。
https://minikube.sigs.k8s.io/
我們就利用這個來實現，下面來說說步驟：
我的本機環境：

大致步驟： https://minikube.sigs.k8s.io/docs/start/macos/

成功之後：

首先描述一下部署要做的事情：linkinstar/mini-go:v1.0 是我已經上傳到 docker-hub 裡面的一個已經做好的最簡單的項目，會暴露一個8080埠的web服務；
最終的目標，在k8s創建一個pod，pod中運行一個我們的容器，最終我們在外部可以訪問到這個服務

執行成功可以再dashboard中查看執行狀態

最終訪問地址查看到服務是否正常：http://192.168.231.146:30008/
其中的ip是通過 minikube ip 命令查看的

在現實的業務環境中，當用戶的訪問增多，我們需要擴展我們的應用，也就是水平的去多部署幾個容器，有了k8s之後這件事就變得非常的容易了。

然後我們就可以看到，原來的一個pod變成了兩個，而k8s會將我們的請求負載均衡到每個pod中。整個過程可以說是非常的優雅了。

同樣的，當我們需要減少服務的數量時也是相同的道理

對於應用的版本升級也是同樣的道理

當我們發現發布的服務問題，想要進行版本回退的時候，就可以使用
kubectl rollout undo deployments/mini-go
進行版本回退，下面是版本回退過程中

當我們使用minikube搭建一個k8s的環境時，如何使用的時候伺服器並不是使用本機進行搭建，那麼會遇到dashboard頁面沒有辦法被外部訪問的問題。解決方式如下：

首先使用minikube dashboard命令啟動

然後記住最下面的訪問地址： http://127.0.0.1:42968/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/

再打開一個sh窗口
使用 kubectl proxy --port=[需要暴露的埠號] --address='[伺服器ip]' --accept-hosts='^[外部訪問伺服器的IP]$' 添加k8s集群對外的訪問代理。

這里的port是你後面通過外網訪問的埠，如果使用雲伺服器記得設置防火牆規則，其中的address為伺服器ip地址可以使用minikube ip命令獲得，我這里允許的是任意機器

http://192.168.1.101:8887/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/#/cronjob?namespace=default

如果上述測試沒有問題使用 nohup 後台啟動就可以了