企业级容器云平台的落地与实践

时间 2020-12-17

标签 html node linux nginx git github web docker shell json 栏目 HTML 繁體版

原文原文链接

随着IT行业的发展和变迁，IT应用的底层支持也从大型机、小型机、PC服务器、虚拟化技术，到现在的容器化。基于敏捷开发的持续迭代，持续部署，以及多样化的技术栈，传统的底层架构变得愈来愈冗杂，运维管理愈来愈力不从心，运维人员也逐步陷落在无尽的“救火”运维模式。html

容器技术的出现，从根本上改变了这一切。而容器高效的编排与管理，才是让其风光无限的前提条件。Kubernetes通过多年的发展，已经成为行业的事实标准。而如何利用好Kubernetes，为企业的发展助力，成为不少企业，尤为是初创企业没法忽略的一道难题。node

本文将介绍利用Amazon EKS打造企业级容器云平台，经过一系列的实践操做，让你们直观地了解AWS是如何帮助企业高效地部署、管理容器化应用。linux

1. 传统应用架构的容器化之路nginx

说到“传统”二字，你们第一反应，就是“落后”，“守旧”，然而现实状况倒是----绝大部分传统应用，依然在良好地运行在这些传统架构中。这些被服务的对象不会由于某些因素对整个系统资源的需求发生很大变化，也不会有频繁的系统功能的迭代开发需求。git

可是随着互联网、大数据、AI等技术的发展，各行各业都在努力地从信息化向智能化转型。而转型的过程当中，愈来愈多的应用场景，和频繁地迭代开发，也让“传统”架构愈来愈庞大。随之而来的是运维人员疲于奔命的“救火”，系统服务愈来愈不稳定，以及系统成本的失控飞涨。github

如何才能从根本上一劳永逸地解决这些问题？容器化/微服务化是不少企业寄予厚望的方向。web

容器化真的那么有效吗？docker

咱们如下图为例。这是一个很通用的架构，在多台服务器上分别部署Tomcat，使用反向代理软件（Nginx）把请求均匀分发到每一个Tomcat中。假定因为11.11促销，咱们须要将现有的3台Tomcat扩充到10台，运维人员须要完成哪些工做？（假设服务器硬件已经准备好）shell

传统系统的扩容步骤：json

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.zip
sudo ./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-1
AWS_DEFAULT_REGION=cn-northwest-1
CLUSTER_NAME=my-zhy-eks
eksctl 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 ready

4.2.3. Eksctl执行以后，须要等待10分钟左右。模式很简单的步骤，实际上是AWS经过调用cloudformation在后台作了许多工做才完成的。下图是cloudformation的stack步骤：

4.2.4. Amazon EKS完成后的，cloudformation状态

4.2.5. 查询node状态信息

#  kubectl get node
NAME                                                STATUS   ROLES    AGE   VERSION
ip-192-168-5-37.cn-northwest-1.compute.internal     Ready    <none>   11m   v1.15.12-eks-31566f
ip-192-168-58-97.cn-northwest-1.compute.internal    Ready    <none>   11m   v1.15.12-eks-31566f
ip-192-168-65-234.cn-northwest-1.compute.internal   Ready    <none>   11m   v1.15.12-eks-31566f

4.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 cluster
NAME            REGION
my-zhy-eks      cn-northwest-1

4.3. Amazon ECR的使用

针对一个企业，不少image都是定制化的，而定制化的私有image管理，在AWS是如何操做的呢？ Amazon ECR，让image的管理，变得更简单易用。下面经过httpd的image，定制化并生成私有httpdok的image以后，并上传到Amazon ECR，做为步骤演示：

4.3.1. 首先建立一个Amazon ECR Repositories，选择并点击View push commands.

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 images
REPOSITORY                                                    TAG                 IMAGE ID            CREATED             SIZE
httpdok                                                       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 images
REPOSITORY                                                     TAG                 IMAGE ID            CREATED             SIZE
<account_id>.dkr.ecr.cn-northwest-1.amazonaws.com.cn/httpdok   latest              9028c4373343        4 minutes ago       299MB
httpdok                                                        latest              9028c4373343        4 minutes ago       299MB

推送image到ECR上

# docker push <account_id>.dkr.ecr.cn-northwest-1.amazonaws.com.cn/httpdok:latest
The 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.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
EOF

执行如下命令，进行部署

kubectl apply -f nginx-deployment.yaml

检查建立状态

kubectl get pods -o wide

4.4.2. 建立LoadBalancer 服务

准备yaml文件

cat <<EOF > loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
EOF

执行如下命令，进行部署

kubectl create -f loadbalancer.yaml

4.4.3. 检查建立状态

kubectl get service
NAME            TYPE           CLUSTER-IP       EXTERNAL-IP                                                                      PORT(S)        AGE
nginx-service   LoadBalancer   10.100.212.244   ae8e75d7e149044eb905b6bbff796e7e-629951941.cn-northwest-1.elb.amazonaws.com.cn   80:31248/TCP   7m53s

4.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 pod
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-574b87c764-92jbs   1/1     Running   0          10h
nginx-deployment-574b87c764-hmz9t   1/1     Running   0          10h
nginx-deployment-574b87c764-nqpmc   1/1     Running   0          10h

4.5.2. 如下命令是肯定pod中nginx的欢迎界面的index.html位置

kubectl exec -it nginx-deployment-574b87c764-92jbs -- /usr/sbin/nginx -t
kubectl exec -it nginx-deployment-574b87c764-92jbs -- cat /etc/nginx/nginx.conf 
kubectl exec -it nginx-deployment-574b87c764-92jbs -- ls /usr/share/nginx/html
kubectl 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 comand

4.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://docs.amazonaws.cn/eks/latest/userguide/what-is-eks.html
https://eksctl.io/usage/creating-and-managing-clusters/
https://github.com/liangruibupt/EKS-Workshop-China
https://docs.amazonaws.cn/en_us/eks/latest/userguide/create-kubeconfig.html
https://amazonaws-china.com/cn/premiumsupport/knowledge-center/eks-kubernetes-services-cluster/
https://www.eksworkshop.com/beginner/130_exposing-service/ingress_controller_alb/
https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/alb-ingress.html