出處：https://www.cnblogs.com/ma159753/p/14219854.html
隨著IT行業的發展和變遷，IT應用的底層支援也從大型機、小型機、PC伺服器、虛擬化技術，到如今的容器化。基於敏捷開發的持續迭代，持續部署，以及多樣化的技術棧，傳統的底層架構變得越來越冗雜，運維管理越來越力不從心，運維人員也逐步陷落在無盡的“救火”運維模式。
容器技術的出現，從根本上改變了這一切。而容器高效的編排與管理，才是讓其風光無限的前提條件。Kubernetes經過多年的發展，已經成為行業的事實標準。而如何利用好Kubernetes，為企業的發展助力，成為很多企業，尤其是初創企業無法忽略的一道難題。
本文將介紹利用Amazon EKS打造企業級容器雲平臺，透過一系列的實踐操作，讓大家直觀地瞭解AWS是如何幫助企業高效地部署、管理容器化應用。
1. 傳統應用架構的容器化之路
說到“傳統”二字，大家第一反應，就是“落後”，“守舊”，然而現實情況卻是----絕大部分傳統應用，依然在良好地執行在這些傳統架構中。這些被服務的物件不會因為某些因素對整個系統資源的需求發生很大變化，也不會有頻繁的系統功能的迭代開發需求。
但是隨著網際網路、大資料、AI等技術的發展，各行各業都在努力地從資訊化向智慧化轉型。而轉型的過程中，越來越多的應用場景，和頻繁地迭代開發，也讓“傳統”架構越來越龐大。隨之而來的是運維人員疲於奔命的“救火”，系統服務越來越不穩定，以及系統成本的失控飛漲。
如何才能從根本上一勞永逸地解決這些問題？ 容器化/微服務化是很多企業寄予厚望的方向。
容器化真的那麼有效嗎？ 我們以下圖為例。這是一個很通用的架構，在多臺伺服器上分別部署Tomcat，使用反向代理軟體（Nginx）把請求均勻分發到每個Tomcat中。假定由於11.11促銷，我們需要將現有的3臺Tomcat擴充到10臺，運維人員需要完成哪些工作？（假設伺服器硬體已經準備好）
傳統系統的擴容步驟：\1. 安裝OS，設定安全和許可權相關
\2. 分配IP，聯網
\3. 部署Tomcat
\4. 以上動作做7遍
僅僅一個擴容，就需要一個資深的運維人員花費幾個小時才能完成。如果要擴充到100個節點呢，工作量成倍增加。
容器化系統擴容步驟： 如果我們使用容器化技術來完成剛剛這件事，就會節省很多人力。
\1. 安裝OS，並由Kubernetes統一管理
\2. 一條命令足以，並且在秒級完成擴充套件
kubectl scale rc tomcat --replicas=10\3. 完成
簡單的一個對比，即可發現，在資源分配，系統穩定（自愈），運維管理等多個方面，容器化技術都可有效地降低企業的成本和運維壓力，並且讓企業保持技術的敏捷性和先進性。
2. 容器化應用場景
容器化很重要的特點，就是輕量化和無狀態。而像傳統的企業應用軟體，承載業務模組眾多，功能流程繁瑣，因此並不適合容器化改造。具體哪些應用場景比較適合呢？主要包含以下幾種場景（當然，這只是幾種常見情況，業務場景滿足輕量化、無狀態的特點都是可以嘗試容器化技術）
2.1. 應用打包
2.2. 多版本混合部署
2.3. 升級回滾
2.4. 多租戶資源隔離
2.5. 內部開發環境
我們一直在說容器化（Docker為代表）的各種優勢，但是企業在真正的生產環境中，如果只是透過Docker來實現容器化，是無法滿足高可用、彈性擴充套件和高併發等場景需求。而Kubernetes的出現，才讓Docker真正在生產環境中被大規模使用起來。Kubernetes提供了應用部署、規劃、更新、維護的一種機制，讓容器化應用的部署和管理更簡單、更高效，。
Kubernetes的特點：
· 可移植: 支援公有云，私有云，混合雲，多雲（multi-cloud）
· 可擴充套件: 模組化，外掛化，可掛載，可組合
· 自動化: 自動部署，自動重啟，自動複製，自動伸縮/擴充套件
Kubernetes結合Docker，讓企業容器化之路變得更加容易，從而更快地滿足業務需求。 但是，事物都是有兩面性，並不是所有專案都適合容器化改造，而且任何的改動都有可能產生未知的影響，要對技術保持敬畏，對生產保持敬畏，才能在容器化的道路上走的更穩。
Kubernetes雖好，但是對於很多初創企業，和沒有太多相關技術積累的傳統企業，Kubernetes的學習成本過高，企業會在底層架構的高可用性、網路、機房等方面遇到一系列問題，從而讓容器化之路滿是荊棘。
3. Amazon EKS助力企業快速實現容器化轉型
如何快速、高效地擁有自己的容器化平臺呢？下面一段，就是AWS官網上Amazon EKS的介紹：
Amazon EKS 是一項託管服務,可讓您在 AWS 上輕鬆執行 Kubernetes,而無需安裝、操作和維護您自己的 Kubernetes 控制層面或節點。Kubernetes 是一個用於實現容器化應用程式的部署、擴充套件和管理的自動化的開源系統。
Amazon EKS 跨多個可用區執行 Kubernetes 控制層面例項以確保高可用性。Amazon EKS 可以自動檢測和替換執行狀況不佳的控制層面例項，併為它們提供自動版本升級和修補。
Amazon EKS 與許多 AWS 服務整合以便為您的應用程式提供可擴充套件性和安全性,包括:
· 用於容器映象的 Amazon ECR
· 用於負載分配的 Elastic Load Balancing
· 用於身份驗證的 IAM
· 用於隔離的 Amazon VPC
Amazon EKS 執行最新版本的開源 Kubernetes 軟體,因此您可以使用 Kubernetes 社群中的所有現有外掛和工具。在 Amazon EKS 上執行的應用程式與在任何標準 Kubernetes 環境中執行的應用程式完全相容，無論此類環境是在本地資料中心還是在公有云中執行都是如此。這意味著,您可以輕鬆地將任何標準 Kubernetes 應用程式遷移到 Amazon EKS,而無需修改任何程式碼。
4. 理論結合實際，讓容器化更直觀
理論說了一大堆，不如動手玩起來。下面，我設計一個場景，在Amazon EKS上逐步完成容器化部署，並逐步在每個環節介紹技術細節。
1） 透過Nginx，做三個頁面web1，web2，web3
2）將三個web頁面作為一組服務，由Amazon EKS管理
3） 透過http訪問，輪詢到三個不同的頁面，來看到效果
註釋：web1，web2，web3實際生產應該是一個業務，只不過為了顯示實驗效果，透過不同的頁面，展示輪詢的效果
4.1. 環境準備4.1.1. 需要一個AWS賬號
4.1.2. 賬號資源限制檢查，確保有足夠的IGW,VPC，EIP等
4.1.3. 安裝awscli（包含eksctl）及配置kubectl：
4.1.3.1. awscli安裝：
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"unzip awscliv2.zipsudo ./aws/install檢查安裝結果
$ aws --version安裝方法參考連結：
https://docs.aws.amazon.com/zh_cn/cli/latest/userguide/cli-chap-install.html
4.1.3.2. 配置kubectl，
aws eks --region cn-northwest-1 update-kubeconfig --name my-zhy-eks官方配置方法連結：
https://docs.amazonaws.cn/eks/latest/userguide/create-kubeconfig.html
4.2. 建立****Amazon EKS叢集：
4.2.1. 建立命令
#命令，引數註釋
--node-type 工作節點型別
--nodes 工作節點數量
CLUSTER_NAME 叢集名稱
AWS_REGION cn-northwest-1：寧夏區； cn-north-1：北京區
建立命令:
AWS_REGION=cn-northwest-1AWS_DEFAULT_REGION=cn-northwest-1CLUSTER_NAME=my-zhy-ekseksctl create cluster --name=${CLUSTER_NAME} --version 1.15 --nodes=3 --node-type t3.medium --managed --alb-ingress-access --region=${AWS_REGION}4.2.2. 成功執行的輸出：
eksctl create cluster --name=${CLUSTER_NAME} --version 1.15 --nodes=3 --node-type t3.medium --managed --alb-ingress-access --region=${AWS_REGION}[ℹ] eksctl version 0.32.0[ℹ] using region cn-northwest-1[ℹ] setting availability zones to [cn-northwest-1b cn-northwest-1c cn-northwest-1a][ℹ] subnets for cn-northwest-1b - public:192.168.0.0/19 private:192.168.96.0/19[ℹ] subnets for cn-northwest-1c - public:192.168.32.0/19 private:192.168.128.0/19[ℹ] subnets for cn-northwest-1a - public:192.168.64.0/19 private:192.168.160.0/19[ℹ] using Kubernetes version 1.15[ℹ] creating EKS cluster "my-zhy-eks" in "cn-northwest-1" region with managed nodes[ℹ] will create 2 separate CloudFormation stacks for cluster itself and the initial managed nodegroup[ℹ] if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=cn-northwest-1 --cluster=my-zhy-eks'[ℹ] CloudWatch logging will not be enabled for cluster "my-zhy-eks" in "cn-northwest-1"[ℹ] you can enable it with 'eksctl utils update-cluster-logging --enable-types={SPECIFY-YOUR-LOG-TYPES-HERE (e.g. all)} --region=cn-northwest-1 --cluster=my-zhy-eks'[ℹ] Kubernetes API endpoint access will use default of {publicAccess=true, privateAccess=false} for cluster "my-zhy-eks" in "cn-northwest-1"[ℹ] 2 sequential tasks: { create cluster control plane "my-zhy-eks", 2 sequential sub-tasks: { no tasks, create managed nodegroup "ng-e5146e45" } }[ℹ] building cluster stack "eksctl-my-zhy-eks-cluster"[ℹ] deploying stack "eksctl-my-zhy-eks-cluster"[ℹ] building managed nodegroup stack "eksctl-my-zhy-eks-nodegroup-ng-e5146e45"[ℹ] deploying stack "eksctl-my-zhy-eks-nodegroup-ng-e5146e45"[ℹ] waiting for the control plane availability...[✔] saved kubeconfig as "/root/.kube/config"[ℹ] no tasks[✔] all EKS cluster resources for "my-zhy-eks" have been created[ℹ] nodegroup "ng-e5146e45" has 3 node(s)[ℹ] node "ip-192-168-5-37.cn-northwest-1.compute.internal" is ready[ℹ] node "ip-192-168-58-97.cn-northwest-1.compute.internal" is ready[ℹ] node "ip-192-168-65-234.cn-northwest-1.compute.internal" is ready[ℹ] waiting for at least 3 node(s) to become ready in "ng-e5146e45"[ℹ] nodegroup "ng-e5146e45" has 3 node(s)[ℹ] node "ip-192-168-5-37.cn-northwest-1.compute.internal" is ready[ℹ] node "ip-192-168-58-97.cn-northwest-1.compute.internal" is ready[ℹ] node "ip-192-168-65-234.cn-northwest-1.compute.internal" is ready[ℹ] kubectl command should work with "/root/.kube/config", try 'kubectl get nodes'[✔] EKS cluster "my-zhy-eks" in "cn-northwest-1" region is ready4.2.3. Eksctl執行之後，需要等待10分鐘左右。模式很簡單的步驟，其實是AWS透過呼叫cloudformation在後臺做了許多工作才完成的。下圖是cloudformation的stack步驟：
4.2.4. Amazon EKS完成後的，cloudformation狀態
4.2.5. 查詢node狀態資訊
# kubectl get nodeNAME STATUS ROLES AGE VERSIONip-192-168-5-37.cn-northwest-1.compute.internal Ready <none> 11m v1.15.12-eks-31566fip-192-168-58-97.cn-northwest-1.compute.internal Ready <none> 11m v1.15.12-eks-31566fip-192-168-65-234.cn-northwest-1.compute.internal Ready <none> 11m v1.15.12-eks-31566f4.2.6. 擴充套件叢集節點方法
我們之前透過eksctl建立了一個3節點的叢集[WHE5] [XX6] ，如果由於業務的增加，希望擴容的話，如何操作呢？具體命令參考如下，將當前叢集，擴容到10個節點：
NODE_GROUP=$(eksctl get nodegroup --cluster ${CLUSTER_NAME} --region=${AWS_REGION} -o json | jq -r '.[].Name')eksctl scale nodegroup --cluster=${CLUSTER_NAME} --nodes=10 --name=${NODE_GROUP} --region=${AWS_REGION}檢查結果
eksctl get nodegroup --cluster ${CLUSTER_NAME} --region=${AWS_REGION}eksctl get clusterNAME REGIONmy-zhy-eks cn-northwest-14.3.Amazon ECR的使用
針對一個企業，很多image都是定製化的，而定製化的私有image管理，在AWS是如何操作的呢？ Amazon ECR，讓image的管理，變得更簡單易用。下面透過httpd的image，定製化並生成私有httpdok的image之後，並上傳到Amazon ECR，作為步驟演示：
4.3.2. 根據”View puhs commands”步驟，將本地建立好的image，上傳到Amazon ECR。
具體命令步驟：
# aws ecr get-login-password --region cn-northwest-1 | docker login --username AWS --password-stdin <account_id>.dkr.ecr.cn-northwest-1.amazonaws.com.cn檢視本地映象
# docker imagesREPOSITORY TAG IMAGE ID CREATED SIZEhttpdok v1 df353399ffe4 7 seconds ago 299MB為映象打標籤
# docker tag httpdok:latest <account_id>.dkr.ecr.cn-northwest-1.amazonaws.com.cn/httpdok:latest在檢視本地Docker的images，可以看到已經出現一個新的，有ECR連線串的image
# docker imagesREPOSITORY TAG IMAGE ID CREATED SIZE<account_id>.dkr.ecr.cn-northwest-1.amazonaws.com.cn/httpdok latest 9028c4373343 4 minutes ago 299MBhttpdok latest 9028c4373343 4 minutes ago 299MB推送image到ECR上
# docker push <account_id>.dkr.ecr.cn-northwest-1.amazonaws.com.cn/httpdok:latestThe push refers to repository [<account_id>.dkr.ecr.cn-northwest-1.amazonaws.com.cn/httpdok]回到aws控制檯，已經可以看到上傳的image
4.4.Amazon EKS例項演示
下面開始部署容器到Amazon EKS中，透過Nginx來演示如何部署image到Amazon EKS，並輪詢訪問.
4.4.1. 啟動三個nginx pod 的 ReplicaSet
準備yaml檔案
cat <<EOF > nginx-deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deployment labels: app: nginxspec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80EOF執行以下命令，進行部署
kubectl apply -f nginx-deployment.yaml檢查建立狀態
kubectl get pods -o wide4.4.2. 建立LoadBalancer 服務
準備yaml檔案
cat <<EOF > loadbalancer.yamlapiVersion: v1kind: Servicemetadata: name: nginx-servicespec: type: LoadBalancer selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80EOF執行以下命令，進行部署
kubectl create -f loadbalancer.yaml4.4.3. 檢查建立狀態
kubectl get serviceNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEnginx-service LoadBalancer 10.100.212.244 ae8e75d7e149044eb905b6bbff796e7e-629951941.cn-northwest-1.elb.amazonaws.com.cn 80:31248/TCP 7m53s4.4.4. 監測網頁顯示情況
curl -silent ae8e75d7e149044eb905b6bbff796e7e-629951941.cn-northwest-1.elb.amazonaws.com.cn | grep title<title>Welcome to nginx!</title>至此，我們已經開始使用EKS上的Nginx叢集了。但是為了建議Load balance的工作效果。我們繼續下面的小實驗，可以更好的觀察load balance的效果
4.5. 輪詢效果展示
4.5.1. 獲取pod資訊
kubectl get podNAME READY STATUS RESTARTS AGEnginx-deployment-574b87c764-92jbs 1/1 Running 0 10hnginx-deployment-574b87c764-hmz9t 1/1 Running 0 10hnginx-deployment-574b87c764-nqpmc 1/1 Running 0 10h4.5.2. 以下命令是確定pod中nginx的歡迎介面的index.html位置
kubectl exec -it nginx-deployment-574b87c764-92jbs -- /usr/sbin/nginx -tkubectl exec -it nginx-deployment-574b87c764-92jbs -- cat /etc/nginx/nginx.conf kubectl exec -it nginx-deployment-574b87c764-92jbs -- ls /usr/share/nginx/htmlkubectl exec -it nginx-deployment-574b87c764-92jbs -- cat /usr/share/nginx/html/index.html kubectl exec -it nginx-deployment-574b87c764-92jbs -- cp/usr/share/nginx/html/index.html /usr/share/nginx/html/index.html.bk註釋：kubectl exce的格式如下：
kubectl exec -it <podName> -c <containerName> -n <namespace> -- shell comand4.5.3. 更改index.html內容
在本地編輯檔案name.html，然後上傳到3個Pod的容器中，
kubectl cp name.html nginx-deployment-574b87c764-nqpmc:usr/share/nginx/html/index.html註釋： pod和本地之間傳輸檔案命令格式
Pod下載檔案到本地
kubectl cp -n NAMESPACE_name POD_name:Pod_FILE_name Local_FILE_name本地上傳檔案到Pod
kubectl cp Local_FILE_name -n NAMESPACE_name POD_name:Pod_FILE_name最終查詢輸出結果，多次查詢，可以看到load balance會將連線隨機分配到不同Pod節點
curl -silent ae8e75d7e149044eb905b6bbff796e7e-629951941.cn-northwest-1.elb.amazonaws.com.cn | grep Node輸出結果如下：
5. 總結
透過本文，大家已經對容器化有一個初步的瞭解，並且針對Amazon EKS打造的企業容器化平臺也有了初步認知。Docker，Kubernetes對於企業的系統和業務的發展，有著不可忽視的“助推力”。
然而，Kubernetes的學習曲線，以及企業的Kubernetes人才的積累,都是需要較長的“時間”成本。而藉助雲計算供應商的成熟平臺和產品，可以降低企業的技術人才的積累成本，從而達到事半功倍的效果。
我們透過這次實戰的演練，可以看到，基於Amazon EKS建立容器化平臺，只需一條命令。Amazon EKS讓Kubernetes的建立，執行與維護變得簡單、可靠。透過AWS Fargate，企業甚至可以完全省去虛擬機器（EC2）的管理，只關注Kubernetes頂層業務架構的邏輯即可，進而可以將更多的“時間”專注在業務的開發，而不是被底層架構的種種問題所拖累，也可以讓運維人員逃離無盡的“救火”式運維模式。
出處：https://www.cnblogs.com/ma159753/p/14219854.html