Share with friends and colleagues on social media

虽然 SUSE CaaS Platform 大大减少了为 Kubernetes 集群管理节点的工作,但是仍有改进的空间。通过利用现代“基础架构即服务”平台(也称为 IaaS或“云”)所提供的灵活性,可以实现更多操作方面的自动化。

 

为了实现这种自动化,Kubernetes 通过“云提供商接口”(CPI) 实现了 Kubernetes 与不同云之间的集成。

SUSE CaaS Platform 云提供商集成

 

SUSE CaaS Platform 3 利用 Kubernetes 云提供商模块实现与不同云解决方案的无缝集成。

 

SUSE CaaS Platform 用户也因此能够利用底层 IaaS 对资源进行自动化管理。这些资源包括负载均衡器、节点(实例)、网络路由和存储服务等;所有这些资源都可以在私有云和公共云中实现。

 

这种集成带来了哪些好处?假设我们想要部署一个利用数据库存储数据的简单 Web 应用程序,比如 WordPress 驱动的网站。

 

 

简化后的“Kubernetes 材料清单”将包含以下项目:

 

  • 一些运行网络前端的 pod
  • 一些运行数据库的 pod
  • 用于存储数据库数据的持久卷

 

启用 CPI 集成后,SUSE CaaS Platform 可以使用本地云存储来分配持久存储。在 OpenStack 之上部署时,它将无缝使用 Cinder 块存储。

 

光是运行我们的应用程序是不够的,我们仍需找到一种方法将其展示给我们的最终用户。为此,云集成允许我们无缝使用由底层 IaaS 提供的“负载均衡器即服务”。回到 OpenStack 示例,我们将使用 OpenStack Neutron 负载均衡器。Kubernetes 还负责更新这个负载均衡器的配置。

 

您可能已经注意到,云提供商集成不但使最终用户免受底层平台实现细节的影响,还提供了一个抽象层,实现了从一个云提供商到另一个云提供商的无缝迁移,使用户能够避免碰到供应商锁定的情况。

 

在具有 CPI的 OpenStack 上部署 SUSE CaaS Platform

 

SUSE CaaS Platform 始终能够在 OpenStack 之上运行。但是,从 3.0 版开始,就可以与这个云基础架构完全集成。

 

要在 OpenStack 上部署 SUSE CaaS Platform,必须首先下载名为 SUSE-CaaS-Platform-3.0-for-OpenStack-Cloud.x86_64.qcow2 的镜像(在 SUSE 网站 www.suse.com 上单击“免费下载”)。

 

接下来,该镜像被上载到 OpenStack Glance 服务。然后,我们可以使用 GitHub 存储库内部的 Heat 模板部署 SUSE CaaS Platform:https://github.com/SUSE/caasp-openstack-heat-templates

 

有关在 OpenStack 上部署 SUSE CaaS Platform 的详细信息,请参阅https://www.suse.com/documentation/suse-caasp-3 上的官方文档。

 

创建所有节点后,打开在 admin 节点上运行的 Web UI 并启动集群配置向导。在第一个配置屏幕上,您将看到一个新的“云提供商集成”框。启用并填写表中要求填写的内容。

上面的屏幕截图显示了 OpenStack 云提供商集成所要求的设置。包括以下选项:

  • OpenStack Keystone API URL:Keystone API 的 URL,用于验证用户身份。该值可在“Access and Security(访问和安全)”>“API Access(API 访问)”>“Credentials(凭据)”下的 OpenStack 控制平面中找到。
  • 域名 ID 或域名(可选):指定用户所属的域名。
  • 项目 ID 或项目名称(可选):指定要在其中创建资源的项目的名称。
  • 区域名称:指定在多区域 OpenStack 云上运行时要使用的区域的标识符。区域是 OpenStack 部署的总称。
  • 用户名:Keystone 中有效用户集的用户名。
  • 密码:Keystone 中有效用户集的密码。
  • CaaS Platform 专用网络的子网 UUID:指定要在其上创建负载均衡器的子网的标识符。该值可在 OpenStack 控制面板上的“Network(网络)”>“Networks(网络)”下找到(单击相应的网络查看其子网)。
  • 浮动网络 UUID(可选):指定后,将为负载均衡器创建浮动 IP。
  • 负载均衡器监视器最大重试次数:在将负载均衡器成员状态更改为 INACTIVE 之前的 ping 失败次数。
  • Cinder 块存储 API 版本:覆盖自动版本检测。有效值为 v1、v2、v3和 auto。指定为 auto 时,自动检测将从 OpenStack 云中选择支持的最高版本。
  • 忽略 Cinder 可用区域:在附加 Cinder 卷时影响可用区域的使用。当 Nova 和 Cinder 具有不同的可用区域时,应该将其设置为“True”。

 

与 OpenStack 云的集成将根据云提供的服务和 Neutron 发布的扩展列表而有所不同。

 

OpenStack 集成实战,持久卷

 

下一段将说明如何利用 OpenStack 集成让 Kubernetes 自动创建由 Cinder Block Storage 支持的持久卷。

首先,我们需要创建一个 Cinder StorageClass:

 

$ cat > cinder-sc.yaml <<EOF
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: cinder
provisioner: kubernetes.io/cinder
EOF
$ kubectl create -f cinder-sc.yaml

 

接下来,我们需要用 StorageClass 创建一个PersistentVolumeClaim:

 

$ cat > cinder-pvc.yaml <<EOF
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: cinder-vol
spec:
storageClassName: cinder
accessModes:
– ReadWriteOnce
resources:
requests:
storage: 5Gi
EOF
$ kubectl create -f cinder-pvc.yaml

 

现在我们可以部署一个简单的容器,利用我们刚刚分配的持久存储:

 

$ cat > busybox-with-cinder.yaml <<EOF
apiVersion: v1
kind: Pod
metadata:
name: busybox
spec:
containers:
– image: busybox
command:
– sleep
– “3600”
imagePullPolicy: IfNotPresent
name: busybox
volumeMounts:
– mountPath: “/data”
name: data
restartPolicy: Always
volumes:
– name: data
persistentVolumeClaim:
claimName: cinder-vol
EOF
$ kubectl create -f busybox-with-cinder.yaml

 

等到 pod 启动并运行,将一些示例数据写入装有 Cinder 卷的 /data。

 

$ kubectl exec -it busybox — /bin/sh -c ‘echo “Hello World!” > /data/test’
$ kubectl delete pod busybox –now

 

等待 pod 被删除,然后再次创建它。

 

$ kubectl create -f busybox-with-pvc.yaml

 

正如您将看到的,先前创建的文件在新启动的容器中仍然可用,并且它的内容正是我们所期望的:

 

$ kubectl exec -it busybox — /bin/sh -c ‘cat /data/test’

 

OpenStack 集成实战,负载均衡器即服务

 

在接下来的段落中,我们将部署一个简单的 Web 应用程序,并通过 Kubernetes 服务将其公开给外部用户。

 

首先,部署一个由 Google 制作的简单的“Hello World”示例应用程序:

 

$ kubectl run hello-world –replicas=5 –labels=”run=load-balancer-example” –image=gcr.io/google-samples/node-hello:1.0 –port=8080

然后通过声明“LoadBalancer”类型的 Kubernetes 服务来公开应用程序:

 

$ kubectl expose deployment hello-world –type=LoadBalancer –name=hello

一段时间后,检查服务的状态:

 

$ kubectl get svc -o wide

输出应该如下所示:

 

$ kubectl get svc -o wide
NAME      TYPE   CLUSTER-IP EXTERNAL-IP    PORT(S) AGE SELECTOR
hello     LoadBalancer  172.24.39.28 < External_IP >  8080:31869/TCP   23m run=load-balancer-example
kubernetes   ClusterIP  172.24.0.1 <none>         443/TCP 6d <none>

可以通过访问 EXTERNAL-IP(本示例中为 10.84.73.198)并使用 8080 端口号,从 Web 浏览器访问 Web 应用程序。

 

 

让我们看看背后发生了什么。当我们使用“LoadBalancer”类型的服务发布时,Kubernetes 与 OpenStack 交互并使用 Neutron 创建了一个负载均衡器。然后,它负责为我们的应用程序请求它的浮动 IP 地址 (10.84.73.198) 并保留端口 8080。

 

Kubernetes 服务将我们的应用程序公开在随机分配的端口(本示例中是 31869)上的集群的所有节点上。每当在集群中添加或移除节点,都必须更新负载均衡器的配置。有了 Kubernetes CPI 集成,集群操作员就不需要执行这项任务;Kubernetes 始终保持配置同步。

 

SUSE CaaS Platform 与公共云的集成

 

如前所述,SUSE CaaS Platform 3 还可以与 Amazon AWS、Google GCE 和 Microsoft Azure 等公共云产品集成。该集成与我们在 OpenStack 中演示的集成类似,这里我们不做深入讨论。

Share with friends and colleagues on social media

Category: Cloud and as a Service Solutions, Containers, Containers as a Service, DevOps, Kubernetes, OpenStack, Solutions, SUSE CaaS Platform, SUSE News
This entry was posted 星期一, 17 九月, 2018 at 6:47 上午
You can follow any responses to this entry via RSS.

发表评论

电子邮件地址不会被公开。 必填项已用*标注

No comments yet