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
2、Deploy Kubernetes Anywhere
https://dzone.com/articles/deploy-kubernetes-anywhere
本文转自kubernetes中文社区-kubernetes落地 |不捧不踩，国外公司向Kubernetes迁移实践
