如果你使用kubernetes作為應用程式的操作平台，那麼你應該會遇到一些有關使用集群的方式的基本問題：
本文將深入討論這些問題，並分析你所擁有的一些選擇的利弊。
作為乙個軟體建立者，你應該開發並執行了多個應用程式。而且，你應該在不同的環境中執行這些應用程式的多個例項——例如，你應該有開發、測試以及生產環境。那麼，不同的環境和應用程式的組合，我們可以得到乙個「矩陣」：
在以上例子中，有3個應用程式和3個環境，兩兩組合為9個應用程式例項。每個應用程式例項是乙個獨立的部署單位，可以獨立執行。
請注意，乙個應用程式例項可能由多個元件組成，如前端、後端、資料庫等。在乙個微服務應用程式中，乙個應用程式例項將由所有微服務構成。
那麼作為乙個kubernetes使用者，此時會遇到一些問題：
以上這些都是行之有效的方法——kubernetes是乙個靈活的系統，它並不會直接告訴你某一條指定的使用方法。
關於集群的搭配你有以下選擇：
前兩種方法分別是大型集群和小型集群的極端，其規模大小關係如下：
總而言之，如果乙個集群包含了大量的節點和pod，那麼它就可以被定義為大於另乙個集群。例如，乙個有10個節點和100pod的集群大於有1個節點和10個pod的集群。
釐清了概念和選項，那麼我們現在開始吧！
這個方法是指將你所有的工作負載都執行在乙個集群中：
通過這種方法，我們可以像通用基礎架構平台一樣使用該集群——無論你需要執行什麼，都可將其部署到現有的kubernetes集群中。
kubernetes中有乙個命名空間的概念，可以 在邏輯上將集群的各個部分彼此分開。在上述情況下，你可以為每個應用程式例項建立單獨的命名空間。
接下來，我們來看看這個方法的優劣勢。
如果你只有乙個kubernetes集群，那麼你只需要擁有執行和管理kubernetes集群所需的所有資源的乙個副本。這包含了master節點——乙個kubernetes集群通常有3個master節點。如果你只擁有乙個集群，你一共只需要3個master節點（比起擁有10個集群，需要30個master節點來說輕鬆不少）。
當然了，肯定不止master節點，還包括其他集群範圍的服務，例如負載均衡器、ingress controller、身份驗證、日誌和監控。如果你只有乙個集群，你可以為所有工作負載重複使用這些服務，並且不需要擁有多個副本。
由於上述原因，較少的集群通常更便宜，因為集群數量較大，意味著資源更多，因此會花費更多的費用。對於主節點來說尤其如此，這可能會用掉你大量的費用——無論你的集群是在本地還是在雲中。
有一些kubernetes託管服務會提供免費的控制平面，如google kubernetes engine（gke）或azure kubernetes service（aks），在這種情況下成本也許就不是問題。然而，有些託管的kubernetes服務會為執行乙個kubernetes集群收取固定的費用，如amazon elastic kubernetes service（eks）。
管理乙個集群總比管理多個集群簡單很多。管理集群可能包含以下任務：
等等……
現在來說說缺點
如果你只有乙個集群，如果這個集群恰好崩潰了，那麼你的所有工作負載都會宕機。
有很多方式可能會導致出錯：
如果只有乙個共享集群，那麼只要類似的事情發生可能會對所有工作負載造成重大損害。
linux容器提供了一些隔離的形式，但這種隔離不如虛擬機器所提供的隔離強。在後台，容器中的程序仍然只是在主機作業系統上執行的程序。
以上所提到的這些也許會成為乙個問題，也許不會，這取決於應用程式對安全性的要求。
kubernetes本身提供了各種方法來防止安全漏洞，如podsecuritypolicies以及networkpolicies。但是，要完全正確地使用這些工具需要一些經驗，並且它們也無法防止所有的安全漏洞。
請牢記一點，kubernetes是為共享而設計的，而不是隔離和安全。
kubernetes提供各種方法來控制這一行為，如resource requests and limits、resourcequota以及limitranges。但是，同樣地，要正確使用這些工具並非易事，而且它們也無法防止所有不必要的***。
如果你只有乙個集群，那麼在企業內部會有許多人必須得訪問這一集群。越多的人訪問，破壞的風險就會越高。
在集群內部，你可以控制哪些人可以使用基於角色的訪問控制（rbac）進行操作。但是，這仍然不能防止使用者在授權範圍內進行破壞。
如果你給所有的工作負載使用乙個集群，這個集群規模大概率已經很大了（從節點和pod的角度來說）。然而，kubernetes集群無法無限擴大。理論上，集群的大小是有上限的，在kubernetes中的定義大概事5000節點、150,000pod以及300,000個容器。
然而，實際上，比上述規模更小的集群已經會開始面臨諸多挑戰，例如500節點。原因是較大的集群對kubernetes控制平面造成了更大的壓力，這需要仔細計畫以保持集群的功能和效率。
接下來，我們來看看第二個選項——許多小型集群
使用這種方法，你可以為每個部署單元使用單獨的kubernetes集群：
在本文中，乙個部署單元即為乙個應用程式例項——如乙個應用程式的開發版本。
通過這種策略，kubernetes就可以像用於各個應用程式例項的專用應用程式執行時一樣使用。
接下來，我們看看這種方法的優勢和劣勢。
如果乙個集群出現故障，那麼僅會損害執行在該集群上的工作負載，並不是所有工作負載都會受到影響。
各個集群中執行的工作負載不會共享資源，如cpu、記憶體、作業系統、網路以及其他服務。這樣可以在不相關的應用程式之間提供強大的隔離，對於提公升應用程式安全性十分有效。
如果每個集群僅執行一小組工作負載，那麼就只需要更少的人訪問這一集群。越少的人訪問集群，集群出現故障的概率就越低。
接下來看一下這一方法的缺點。
低效的資源利用自然就會導致更高的成本。例如，如果你必須執行30個master節點，而不是3個才能獲得相同的計算機功能，你看看每月的賬單就能體會到這一點。
同時管理許多kubernetes集群比管理單個集群要複雜得多。例如，你需要為每個集群設定身份驗證和授權；如果你想公升級kubernetes版本，你需要執行這一操作很多次。你可能需要開發一些自動化流程，這樣會使這些操作更高效。
接下來，我們看一下其他場景的集群。
使用這種方法，對於特定應用程式的所有例項，你都有乙個單獨的集群：
你可以將其視為每個團隊單獨擁有自己的集群，因為通常乙個團隊會開發乙個或多個應用程式。
接下來，我們看看這個方法的優劣。
如果乙個應用程式有特定的需求，這些需求可以在它的集群內安裝，而無需影響其他集群。這樣的要求可能包括gui worker節點、乙個特定的cni外掛程式、乙個服務網格或其他服務。如此以來，每個集群都可以完全配備相應應用程式所需的配置——不多也不少。
這個方法的乙個不足時來自不同環境的應用程式例項執行在同乙個集群中。例如，應用程式的生產版本和開發版本都執行在同乙個集群中，這意味著開發人員需要在生產版本應用程式執行的相同集群中工作。
所以，如果開發人員或乙個有bug的開發版本在集群中造成了某些損害，那麼生產版本絕對會因此受到影響——這是乙個巨大的不足。
使用這種方法，你可以為每個環境建立乙個單獨的集群：
例如，你可以分別有乙個開發、測試和生產集群，你可以在其中執行特定環境中的所有應用程式例項。
你可以為環境優化每個集群，例如：
沒有人真的需要在生產集群內工作，所以你可以限制訪問它。你甚至可以根本不向任何人授予生產集群的訪問許可權——可以通過自動化ci/cd工具對該集群進行部署。這將極大降低生產集群中人為錯誤的風險，這十分重要！
現在，來看看缺點。
這一方法的主要不足是應用程式之間缺少硬體和資源的隔離。不相關的應用程式共享集群資源，例如操作洗頭膏核心、cpu、記憶體和其他服務。如上文所述，這可能是乙個安全問題。
所以你應該選擇哪種方法呢？
通常情況下，這取決於你的實際用例——你必須權衡不同方法的優缺點，才能找到最合適你的解決方案。但是，選擇不僅限於上述示例，也可以是它們的任意組合。例如，您可能考慮為每個團隊建立兩個集群：乙個開發集群（用於開發和測試環境）和乙個生產集群（用於生產環境）。
通過了解以上示例方案，您可以相應地結合特定方案的利弊。
k8s 執行應用
kubect建立deployment deployment 建立replicaset 根據replicaset 建立pod 命名方式 relicaset 的命名方式 deployment名稱 隨機數 pod命名方式 relicaset 隨機數 1 通過kubetcl 建立 kubectl run n...
在k8s上面執行第乙個應用
kubectl run kubia image luksa kubia port 8080 image 指定要執行的容器映象 generator建立乙個 replicationcontroller而不是deployment 該引數現已被廢棄 kubectl expose pod kubia type...
k8s 部署第乙個應用
1 建立yaml檔案 vim nginx deploy.yaml apiversion kind deployment metadata name nginx pod spec replicas 1 selector matchlabels nginx pod template metadata l...