超级会员免费看
Kubernetes在AWS和GCP上的部署与升级指南
1. Kubernetes在AWS EKS上的应用
1.1 使用Network Load Balancer（NLB）
EKS已开始支持使用AWS的新型L4负载均衡器Network Load Balancer（NLB）。若要使用NLB，需要添加额外的注解，示例如下：
metadata:
name: nginx-external
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
1.2 升级Kubernetes版本
当Kubernetes发布新版本时，EKS会及时为用户提供最新版本。以下是在EKS上升级Kubernetes版本的典型步骤：
1. 升级Kubernetes主节点 ：通过AWS CLI指定EKS名称和期望的新版本，此操作大约需要30分钟完成。在此期间，通过 kubectl 访问Kubernetes API服务器可能会失败，但Pod和服务不受影响。
$ aws eks update-cluster-version --name chap10 --kubernetes-version 1.11
执行上述命令后，会返回一个更新ID，可使用该ID检查升级状态：
$ aws eks describe-update --name chap10 --update-id 09688495-4d12-4aa5-a2e8-dfafec1cee17
当状态从 InProgress 变为 Successful 时，可通过以下命令查看API服务器的新版本：
$ kubectl version --short
- 升级工作节点 ：目前尚无AWS CLI支持，需要手动执行以下步骤：
$ vi aws-auth-cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
#
# new version of Worker Nodes
#
- rolearn: arn:aws:iam::xxxxxxxxxxxx:role/chap10-v11-NodeInstanceRole-10YYF3AILTJOS
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
#
# old version of Worker Nodes
#
- rolearn: arn:aws:iam::xxxxxxxxxxxx:role/chap10-worker-NodeInstanceRole-8AFV8TB4IOXA
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
$ kubectl apply -f aws-auth-cm.yaml
- **迁移Pod**：通过`taint`和`drain`操作将旧节点上的Pod迁移到新节点：
$ kubectl taint nodes ip-10-0-2-218.ec2.internal key=value:NoSchedule
$ kubectl taint nodes ip-10-0-4-74.ec2.internal key=value:NoSchedule
$ kubectl drain ip-10-0-2-218.ec2.internal --ignore-daemonsets --delete-local-data
$ kubectl drain ip-10-0-4-74.ec2.internal --ignore-daemonsets --delete-local-data
- **移除旧节点**：从集群中移除旧节点并再次更新ConfigMap：
$ kubectl delete node ip-10-0-2-218.ec2.internal
$ kubectl delete node ip-10-0-4-74.ec2.internal
$ kubectl edit configmap aws-auth -n kube-system
1.3 AWS EKS的优缺点
- 优点 ：AWS是最流行的公共云服务，提供API以编程方式控制基础设施。EKS使在AWS上部署Kubernetes变得容易，控制平面采用高可用性设计，减轻了大量管理工作。
- 缺点 ：升级Kubernetes版本需要一定的AWS知识，涉及多个步骤和技术难度。使用ALB作为入口控制器需要额外的配置工作。
2. Google Cloud Platform（GCP）简介
2.1 GCP概述
GCP由谷歌提供，在公共云行业中越来越受欢迎。它提供了与AWS类似的概念，如VPC、Compute Engine、Persistent Disk、Load Balancing和多个托管服务。对于Kubernetes用户来说，最重要的服务是Google Kubernetes Engine（GKE），这是一个托管的Kubernetes服务，可减轻Kubernetes的安装、升级和管理工作。
2.2 GCP组件及使用
2.2.1 访问GCP
GCP提供了Web控制台和命令行界面（CLI），使用时需要Google账户。若要通过CLI控制GCP组件，需安装Cloud SDK，并通过以下命令进行配置：
$ gcloud init
2.2.2 VPC
GCP的VPC策略与AWS不同，无需为VPC设置CIDR前缀，而是直接向VPC添加子网。GCP VPC有自动和自定义两种子网模式：
- 自动模式 ：使用以下命令创建自动模式的VPC，它会在每个区域创建预定义CIDR块的子网：
$ gcloud compute networks create my-auto-network --subnet-mode auto
自动模式适合初学者，但无法指定CIDR前缀，且所有区域的18个子网可能不适合某些使用场景。
- 自定义模式 ：使用以下命令创建自定义模式的VPC，然后手动添加具有所需CIDR前缀的子网：
$ gcloud compute networks create my-custom-network --subnet-mode custom
添加子网示例：
$ gcloud compute networks subnets create subnet-a --network=my-custom-network --range=10.0.1.0/24 --region=us-west1
$ gcloud compute networks subnets create subnet-b --network=my-custom-network --range=172.16.1.0/24 --region=us-east1
$ gcloud compute networks subnets create subnet-c --network=my-custom-network --range=192.168.1.0/24 --region=asia-northeast1
2.2.3 子网
GCP的子网跨区域的多个可用区，创建子网时需指定整个区域。与AWS不同，GCP没有明显的公共和私有子网概念，所有子网都有通往互联网网关的路由。GCP使用网络标签进行主机级别的访问控制，以确保网络安全。
2.2.4 防火墙规则
GCP的防火墙规则比AWS的安全组更简单灵活。防火墙规则和VM实例通过网络标签松散耦合，以下是创建防火墙规则的示例：
$ gcloud compute firewall-rules create public-ssh --network=my-custom-network --allow="tcp:22" --source-ranges="0.0.0.0/0" --target-tags="public"
$ gcloud compute firewall-rules create public-http --network=my-custom-network --allow="tcp:80" --source-ranges="0.0.0.0/0" --target-tags="public"
$ gcloud compute firewall-rules create private-ssh --network=my-custom-network --allow="tcp:22" --source-tags="public" --target-tags="private"
$ gcloud compute firewall-rules create internal-icmp --network=my-custom-network --allow="icmp" --source-tags="public,private"
2.2.5 VM实例
GCP的VM实例与AWS EC2类似，可选择不同硬件配置的机器类型和操作系统。在启动VM实例之前，需要创建SSH公钥：
$ gcloud compute config-ssh
以下是在GCP上启动VM实例的示例：
$ gcloud compute instances create public-on-subnet-a --machine-type=f1-micro --network=my-custom-network --subnet=subnet-a --zone=us-west1-a --tags=public
$ gcloud compute instances create public-on-subnet-b --machine-type=f1-micro --network=my-custom-network --subnet=subnet-b --zone=us-east1-c --tags=public
$ gcloud compute instances create private-on-subnet-a --machine-type=g1-small --network=my-custom-network --subnet=subnet-a --zone=us-west1-a --tags=private
可通过以下命令查看创建的VM实例列表：
$ gcloud compute instances list
2.3 验证防火墙规则
可登录到创建的机器上验证防火墙规则是否按预期工作。首先，将SSH密钥添加到 ssh-agent ：
$ ssh-add ~/.ssh/google_compute_engine
然后，验证ICMP防火墙规则是否能拒绝外部流量，以及公共主机是否允许SSH连接。还可以在私有主机上安装Tomcat，并在公共主机上安装Nginx：
$ ssh 35.196.228.40 "sudo apt-get -y install nginx"
$ ssh 35.199.171.31 "sudo apt-get -y install nginx"
$ curl -I http://35.196.228.40/
2.4 GCP的优缺点
- 优点 ：GKE是托管的Kubernetes服务，可减轻管理工作。GCP的VPC和防火墙规则设计更灵活，便于网络扩展。
- 缺点 ：需要一定的GCP基础知识，如使用Cloud SDK和理解网络标签的概念。
3. 总结
本文介绍了在AWS EKS和GCP GKE上部署和管理Kubernetes的方法。AWS EKS适合熟悉AWS基础设施的用户，而GCP GKE则为用户提供了更成熟的托管Kubernetes服务。在选择时，用户应根据自身需求和技术栈进行综合考虑。
3.1 对比表格
| 对比项 | AWS EKS | GCP GKE |
|---|---|---|
| 服务成熟度 | 相对较新，仍需改进 | 更成熟 |
| 管理难度 | 升级需一定AWS知识 | 托管服务，管理更轻松 |
| 网络灵活性 | 传统VPC和安全组 | VPC和防火墙规则更灵活 |
| 成本 | 按使用量计费 | 按使用量计费 |
3.2 流程图
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
A[选择云平台]:::process --> B{AWS EKS}:::process
A --> C{GCP GKE}:::process
B --> D[使用NLB]:::process
B --> E[升级Kubernetes版本]:::process
C --> F[了解GCP组件]:::process
C --> G[使用GKE]:::process
通过以上内容，你可以根据自己的需求和技术背景，选择适合的云平台来部署和管理Kubernetes集群。在实际操作中，建议仔细阅读相关文档，并进行充分的测试。
4. AWS EKS与GCP GKE的技术细节分析
4.1 网络负载均衡器与防火墙规则对比
4.1.1 AWS EKS的NLB
在AWS EKS中，使用Network Load Balancer（NLB）需要添加特定注解。以下是详细步骤：
1. 添加注解 ：在服务的元数据中添加注解，示例如下：
metadata:
name: nginx-external
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
- 原理 ：NLB是AWS的新型L4负载均衡器，通过注解告知Kubernetes使用该负载均衡器，实现对流量的高效分发。
4.1.2 GCP的防火墙规则
GCP的防火墙规则通过网络标签进行灵活配置。以下是创建不同类型防火墙规则的示例及原理：
- 公共主机SSH访问规则 ：
$ gcloud compute firewall-rules create public-ssh --network=my-custom-network --allow="tcp:22" --source-ranges="0.0.0.0/0" --target-tags="public"
原理：允许任何来源的流量通过TCP 22端口访问带有“public”标签的主机。
- 公共主机HTTP访问规则 ：
$ gcloud compute firewall-rules create public-http --network=my-custom-network --allow="tcp:80" --source-ranges="0.0.0.0/0" --target-tags="public"
原理：允许任何来源的流量通过TCP 80端口访问带有“public”标签的主机。
- 私有主机SSH访问规则 ：
$ gcloud compute firewall-rules create private-ssh --network=my-custom-network --allow="tcp:22" --source-tags="public" --target-tags="private"
原理：允许带有“public”标签的主机通过TCP 22端口访问带有“private”标签的主机。
- 内部ICMP访问规则 ：
$ gcloud compute firewall-rules create internal-icmp --network=my-custom-network --allow="icmp" --source-tags="public,private"
原理：允许带有“public”或“private”标签的主机之间进行ICMP通信。
4.2 Kubernetes版本升级对比
4.2.1 AWS EKS升级流程
AWS EKS升级Kubernetes版本需要分别对主节点和工作节点进行操作，具体步骤如下：
1. 升级主节点 ：
$ aws eks update-cluster-version --name chap10 --kubernetes-version 1.11
此操作大约需要30分钟，期间通过 kubectl 访问Kubernetes API服务器可能会失败。可使用返回的更新ID检查升级状态：
$ aws eks describe-update --name chap10 --update-id 09688495-4d12-4aa5-a2e8-dfafec1cee17
- 升级工作节点 ：
- 创建新工作节点，指定新的AMI版本，如
ami-0b4eb1d8782fc3aea。 - 更新安全组，允许新旧工作节点之间的网络流量。
- 更新ConfigMap，添加新工作节点的实例ARN：
- 创建新工作节点，指定新的AMI版本，如
$ vi aws-auth-cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
#
# new version of Worker Nodes
#
- rolearn: arn:aws:iam::xxxxxxxxxxxx:role/chap10-v11-NodeInstanceRole-10YYF3AILTJOS
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
#
# old version of Worker Nodes
#
- rolearn: arn:aws:iam::xxxxxxxxxxxx:role/chap10-worker-NodeInstanceRole-8AFV8TB4IOXA
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
$ kubectl apply -f aws-auth-cm.yaml
- 通过`taint`和`drain`操作迁移Pod：
$ kubectl taint nodes ip-10-0-2-218.ec2.internal key=value:NoSchedule
$ kubectl taint nodes ip-10-0-4-74.ec2.internal key=value:NoSchedule
$ kubectl drain ip-10-0-2-218.ec2.internal --ignore-daemonsets --delete-local-data
$ kubectl drain ip-10-0-4-74.ec2.internal --ignore-daemonsets --delete-local-data
- 移除旧节点并再次更新ConfigMap：
$ kubectl delete node ip-10-0-2-218.ec2.internal
$ kubectl delete node ip-10-0-4-74.ec2.internal
$ kubectl edit configmap aws-auth -n kube-system
4.2.2 GCP GKE升级流程
GCP GKE作为托管的Kubernetes服务，升级相对简单，通常由Google自动处理。用户只需在控制台或通过CLI发起升级请求，GKE会自动完成主节点和工作节点的升级，减少了用户的手动操作。
4.3 网络架构对比
4.3.1 AWS EKS的网络架构
AWS EKS使用传统的VPC和安全组进行网络隔离和访问控制。Pod和持久卷需要考虑可用性区域的关联性，子网分为公共子网和私有子网，分别通过互联网网关（IGW）和NAT网关进行网络访问。
4.3.2 GCP GKE的网络架构
GCP GKE的VPC和子网设计更加灵活。VPC无需设置CIDR前缀，可直接添加不同CIDR前缀的子网。子网跨区域的多个可用区，所有子网都有通往互联网网关的路由。GCP使用网络标签进行主机级别的访问控制，简化了网络管理。
5. 实际应用场景与选择建议
5.1 不同场景下的选择
| 应用场景 | 推荐平台 | 原因 |
|---|---|---|
| 熟悉AWS生态系统 | AWS EKS | 与AWS现有基础设施集成方便，可利用AWS的各种服务和工具。 |
| 需要更成熟的托管服务 | GCP GKE | GKE提供更自动化的管理，减少用户的管理工作量。 |
| 对网络灵活性要求高 | GCP GKE | GCP的VPC和防火墙规则设计更灵活，便于网络扩展和配置。 |
| 有大量EC2实例 | AWS EKS | 可与现有的EC2实例更好地协同工作，降低迁移成本。 |
5.2 选择流程图
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
A[确定应用场景]:::process --> B{熟悉AWS生态}:::process
A --> C{需要成熟托管服务}:::process
A --> D{对网络灵活性要求高}:::process
A --> E{有大量EC2实例}:::process
B -- 是 --> F[选择AWS EKS]:::process
B -- 否 --> G[继续评估]:::process
C -- 是 --> H[选择GCP GKE]:::process
C -- 否 --> G
D -- 是 --> H
D -- 否 --> G
E -- 是 --> F
E -- 否 --> G
6. 总结与展望
6.1 总结
本文详细介绍了在AWS EKS和GCP GKE上部署和管理Kubernetes的方法，包括网络负载均衡器、防火墙规则、Kubernetes版本升级、网络架构等方面的技术细节。通过对比分析，我们了解了两者的优缺点和适用场景。
6.2 展望
随着云计算和Kubernetes技术的不断发展，AWS EKS和GCP GKE都将不断改进和完善。未来，我们可以期待更自动化、更灵活的管理方式，以及更好的性能和安全性。在选择云平台时，用户应持续关注技术发展趋势，结合自身需求做出更明智的决策。
扫一扫
1367
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
