kubernetes落地 |不捧不踩,国外公司向Kubernetes迁移实践

导读:

Kubernetes一骑绝尘开挂来,那么企业应该开始向Kubernetes迁移吗?什么情况下真正的接受它?一些技术前沿公司先行一步的实践恐怕最有说服力和参考价值。本文即是一则很好的参考。

1

Kubernetes如今风靡一时,它是庞大的云原生运动中的一部分。所有主要的云提供商都将其作为部署云原生应用的解决方案。就在几个星期前,AWS重新推出了EKS(Amazon Elastic Container Service for Kubernetes),这是一个完全托管的Kubernetes集群。

这是一个巨大的进步,因为AWS是最大的公有云提供商,大多数Kubernetes的部署都在AWS上。官方kops工具用于部署和管理Kubernetes集群,目前已准备就绪。随着Kubernetes越来越受欢迎,企业正在努力接受它,希望借助Kubernetes解决许多常见问题。

那么,企业真的应该开始向Kubernetes迁移吗?什么情况下真正的接受它?本篇文章,将试图回答这个问题,并给出迁移到K8S和云原生的一些挑战和建议。

The Problem 问题

今年早些时候,我们开始对Sematext云进行容器化部署,这看起来似乎非常简单。企业所要做的就是将所有应用程序打包,为其资源(如部署、服务等)创建一些Kubernetes配置,然后即可进行操作。然而,并不是那么容易。

问题主要在于,用于管理发布过程的所有东西都不适合云原生模式。企业的应用程序不是云原生的,就无法使用CI/CD部署管道,运行状况检查或使用监视工具来记录日志、指标和警报。企业的应用程序可能非常静态且部署复杂。这种复杂性不会随着迁移到Kubernetes而消失,只会让事情变得更糟。云原生意味着将操作系统从应用程序中解耦出来,这就是容器正在做的事情。

在软件行业的演进中,首先是瀑布流,然后是敏捷,如今有了DevOps管理。这是一个非常重要的难题,这里没有规则可循。每个团队使用最适合他们的方式,如果你想坚持现有的常规,没什么问题,请照常做。只需要确保你的日常工作适用于云原生,这意味着需要做出一些改变。要切换整个团队来接受DevOps原则并不容易,需要一些时间做准备。

The Solution解决方案

这不是一个需要盲目跟随的解决方案。它给出一个想法,并解释可能遇到的过程和问题。

第一步,首先对所有未使用的组件进行清理。软件在开发了几年之后,会变得非常复杂,因为总有更重要的事情要做——新功能、新产品修复等等。

其次,对Kubernetes readiness and liveness probes进行健康检查,这点不难。花费时间管理配置才是最难的部分。我的建议是利用配置地图(config maps)和secrets ,远离环境变量。你可以使用其中一部分,但不要仅使用环境变量来进行整个配置管理。应用程序应该充分发挥Kubernetes的潜力。

Kubernetes应用程序正在使用服务进行通信。在Kubernetes中有不同类型的服务,并将它们视为负载均衡器。定义的服务名称是你的端点http://service_name:port。如果正在使用有状态应用程序,会希望使用 headless services,能够访问特定的Pod。Kubernetes的服务也在某种程度上解决了服务发现问题。如果你已经使用了Consul之类的服务发现,恭喜你!可以坚持下去,并将它部署在Kubernetes上。

从Kubernetes的角度来看,在无状态应用程序下,应用程序容易扩展。使用部署作为资源,这种类型的服务还可以管理简单的升级-滚动更新。当然,你的应用程序需要在没有任何问题的情况下处理扩展,并且需要一些代码更改来实现它。

主要问题在于有状态的应用程序,如数据库。Kubernetes为这类应用程序提供了一种StatefulSet资源,但不知道在添加新节点或出现故障时,特定的应用程序应该如何反应,这是运维人员在管理时通常要做的事情。不过,编写Kubernetes的操作符不是多么困难的事情。

简而言之,操作符是Kubernetes custom resource definition(即CRD),可以自行编写或使用现有的。我们使用的是 Elastic search Operator,很乐意为这个项目做出贡献。我已经提出了一些pull requests。

你可能已经开始把所有的片段连接起来了。有两种计算资源:请求,它在一个节点上指定最小数量的空闲资源,用于Kubernetes调度程序运行特定的Pod,以及限制,这是Pod可以使用的最大计算资源数量。这一点非常重要,特别是对于Java应用程序来说。对于Java应用,还需要根据heap memory需求调整限制。根据对Docker CPU和内存限制的了解,我的建议是使用Java version 8u131或更新版本。

给你的应用标上标签——当需要监控容器和应用程序时,这真的很有用,而元数据信息通常就是如何通过选择器连接不同的资源。例如,部署和服务。

当开始编写Kubernetes配置文件时,你会觉得很好,并且认为维护不是什么大问题。但是,在尝试实现部署管道时,你会发现使用一堆配置文件是一个非常糟糕的想法。这时Helm可以拯救,Helm是一个用于打包Kubernetes应用程序的工具,我强烈推荐使用它来部署管道。诸如支持多种环境、依赖关系、版本控制、回滚和不同hooks(考虑DB迁移)就足够描述Helm的所有优点了。坏消息是你需要学习另一种工具,但它很容易学,值得你花时间。

企业不需要多个集群来搭建不同的环境,只需使用不同的Kubernetes命名空间。例如,为了创建一个新环境,只需要创建一个单独的命名空间,完成测试后把它删除,节省了大量时间和资金。但是,不要忘记安全。Kubectl就像集群中的根用户。让每个人都访问kubectl可能不是一个好主意。有时,创建一个全新的集群比管理RBAC更好,而这可能非常复杂。尽管如此,还是强烈建议使用RBAC。

那么,企业将如何为容器镜像、Helm packages等提供版本呢?这取决于自己的选择。最常用的方法是提交ID给镜像打标签,然后release tag。此时,需要将Docker镜像存储到某个地方,即私人或公共注册中心。我的建议是使用DockerHub。这或许是最具成本效益的。如果解决了所有问题,那么需要创建一个部署管道。企业可以使用Jenkins来部署所有内容,并将其作为DevOps的主要工具之一。

The Conclusion 结论

最近,人们关注的焦点是云原生,而并非仅仅Kubernetes本身。Kubernetes只是一个工具,我们向Kubernetes迁移Sematext云和Sematext的工作正在进行中。需要把它看作一个过程,这不是一项一次性的工作,也从来没有完全完成。

迁移到云原生和Kubernetes的过程,既困难又费时,但对企业的公司文化和软件非常有益。扩展不再是问题,基础设施只是代码和软件问题。拥抱Kubernetes,但要准备好面对挑战。

 

2

Kubernetes可以在任一环境下部署

在开始进行云原生开发和部署时,来看看Kubernetes所扮演的角色,以及如何从编排中获得更多的功能。

容器提供了将应用程序及其依赖与操作系统分离的能力。通过与虚拟机镜像不同的方式打包操作系统,容器节省了大量系统资源:计算、内存和磁盘空间。容器也更快地下载、更新、部署和迭代。因此,在技术领域,容器已经引起了一场小型革命,并被谷歌、微软和亚马逊等公司采用。

容器的小型革命也带来了激烈的竞争,以满足编排和管理的需要。Kubernetes,谷歌的开源容器编排工具,已经成为领先的解决方案(替代方案有有亚马逊ECS和DockerSwarm等),归功于三个主要原因:

  • 云原生设计:支持部署和运行下一代应用程序。
  • 开源特性:快速创新,避免厂商锁定。
  • 可移植性:在任何地方部署,无论是在云中、on-premise、还是虚拟机中等等。

下图显示了Kubernetes在云原生部署中所扮演的角色:

Kubernetes容器编排

Kubernetes可以部署和管理容器应用,其中包括NGINX、MySQL、Apache和其他许多应用程序。它可以为容器提供布局、缩放、复制、监视和其他功能。

一旦选择了容器编排平台,下一步就是部署Kubernetes。如前所述,Kubernetes是一个可移植的解决方案。因为Kubernetes使用相同的镜像和配置,它在笔记本电脑上、云里、或在本地所使用的方式完全相同。

Kubernetes-as-a-Service

这些解决方案提供了在各种基础设施中部署Kubernetes的能力:公有云或内部部署。为Kubernetes集群选择这种方法的优势包括:

1.通过KaaS供应商进行升级、监控和支持。

2.轻松扩展混合云或多云环境。

3.多集群的单一窗格视图。

4.高可用性,多主Kubernetes集群,根据工作负载自动扩缩。

5.通用企业集成,如SSO /独立命名空间; 以及通过Helm图表部署应用程序的能力。

6.集群联合,提供跨多个云或数据中心的真正无缝混合环境。

Kubernetes-as-a-Service(Kubernetes即服务)

Kubernetes即服务的例子包括Platform9和StackPoint.io。

 

托管的基础设施

谷歌云平台和Microsoft Azure分别通过谷歌容器引擎(GKE)和Azure容器服务(ACS)提供Kubernetes。容器放置在公有云中可以快速启动,但是现在企业的数据将留存在网络防火墙之外。

谷歌GKE领导着其他公有云供应商。谷歌通过一个名为Borg的集群管理器,广泛地将容器用于内部项目,并拥有超过十年的开发经验(来源: TheNextPlatform)。相比之下,微软的ACS是一个更年轻的产品,Kubernetes支持仅在2017年2月才被引入。

然而,ACS提供了灵活性:用户可以选择容器编排平台(Kubernetes, Docker Swarm, DCOS),以及选择除了Linux以外,在Windows中部署容器化的应用程序的选项。如下所示,GKE和ACS完全基于公有云,Kubernetes服务和基础设施由托管提供商部署和管理。

Hosted Infrastructure for Kubernetes

本地部署

Minikube是在本地部署Kubernetes最流行的方式。它支持各种虚拟化管理程序,包括VirtualBox、VMware Fusion、KVM、xhyve和OSs,包括OSX、Windows和Linux。下面的插图进一步描述了Minikube的部署:

部署与Minikube

如上所示,用户使用Minikube CLI和Kubernetes的原生CLI Kubectl与笔记本电脑部署进行交互。 Minikube CLI可用于在虚拟机上启动,停止,删除,获取状态以及执行其他操作。一旦Minikube虚拟机启动,Kubectl CLI将在Kubernetes群集上执行操作。 以下命令启动现有的Minikube虚拟机并创建NGINX Kubernetes部署:


#  minikube start
# cat > example.yaml<<EOF
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
– name: nginx
image: nginx
ports:
– containerPort: 80
EOF
# kubectl create -f example.yaml

(手动往下翻)

原文链接:

1、Embracing Kubernetes Successfully

Embracing Kubernetes Successfully

2、Deploy Kubernetes Anywhere

https://dzone.com/articles/deploy-kubernetes-anywhere

推荐活动:

数人云联合ServiceComb、ServiceMesh社区举办的 Building Microservice Meetup系列活动第2站–3月31日,北京站开始报名啦!本期主题为微服务,从架构到发布》依旧大咖汇集,点击最下方的链接快来报名~

相关阅读:

后Kubernetes时代,带你系统梳理K8S 12大关键特性

女神特辑 | 关于DevOps和职场,4位DevOps领域杰出女性都关注些啥?

【详解】以银行零售业务为例,一个案例说清楚可视化微服务架构

有趣 | 马斯洛理论告诉你,Kubernetes可以满足微服务的这15大需求