如何知道Kubernetes是否适合您的SaaS

Kubernetes is an awesome technology, and I personally have seen great gains in my ability to scale, deploy, and manage my own SaaS because of it. But, not everyone would immediately benefit from adopting it for a number of reasons:

Kubernetes是一项了不起的技术，因此，我个人已经看到了扩展，部署和管理自己的SaaS的能力方面的巨大进步。 但是，由于多种原因，并非所有人都会立即从采用它中受益：

• Lack of familiarity with container technology
  缺乏对集装箱技术的了解
• Application architecture not being conducive to utilizing the benefits of Kubernetes
  应用程序架构不利于利用Kubernetes的优势
• Increased amount of effort versus time spent
  与花费的时间相比，增加的工作量

If you are interested in Kubernetes but aren’t sure about investing the time/resources needed, this article is for you.

如果您对Kubernetes感兴趣，但是不确定要花费所需的时间/资源，那么本文适合您。

您对容器的使用经验是什么？ ？ (What is your experience with containers? ?)

In order to understand what Kubernetes can do for you, you first need to know what benefits containers provide. Before spending time on Kubernetes you should first:

为了了解Kubernetes可以为您做什么，您首先需要知道容器可以提供什么好处。 在花时间学习Kubernetes之前，您应该首先：

容器化您的应用程序 (Containerize your application)

First and foremost, your application must be containerized. This means defining the steps needed to take a base OS image and install your application on it in a file (usually a Dockerfile).

首先，必须将应用程序容器化。 这意味着需要定义获取基本OS映像并将应用程序安装在文件中(通常是Dockerfile)的步骤。

Going through this process as well as defining environment variables needed to configure your application (such as the URL, username, and password of the database your app uses) will be critical to making your container image usable by Kubernetes.

完成此过程以及定义配置应用程序所需的环境变量(例如应用程序使用的数据库的URL，用户名和密码)对于使Kubernetes可以使用容器映像至关重要。

Also make note of any dependencies your application needs to function and learn how to use the containerized versions of those.

还要记下您的应用程序运行所需的任何依赖关系，并了解如何使用这些依赖关系的容器化版本。

了解存储如何工作 (Understand how storage works)

Containers are designed to hold only the code needed to run an application. Any persistent data needs to be stored elsewhere, as the process of tearing down and spinning up containers (very common when dealing with containers) also destroys any data stored within the file system of that container.

容器被设计为仅包含运行应用程序所需的代码。 任何持久性数据都需要存储在其他位置，因为拆解和旋转容器的过程(在处理容器时很常见)也会破坏该容器的文件系统中存储的所有数据。

Knowing how container storage is supposed to work and how to handle things like backing up data, moving that data between containers, and accessing the data from outside the container is very valuable when considering Kubernetes.

在考虑使用Kubernetes时，了解容器存储应该如何工作以及如何处理诸如备份数据，在容器之间移动数据以及从容器外部访问数据之类的事情非常有价值。

Kubernetes makes storage management easier with features such as auto-provisioning. This has the ability to have your storage provider (such as AWS EBS) create new volumes on the fly as new containers are created, automatically mounting them.

Kubernetes通过自动配置等功能使存储管理更加容易。 这样可以让您的存储提供商(例如AWS EBS)在创建新容器时即时创建新卷，并自动挂载它们。

了解网络如何工作 (Understand how networking works)

How you implement networking can play a large role in how you use Kubernetes. Knowing how to open specific systems to the public internet and hiding others, such as databases, while maintaining communication between services is important to understand for starters. Some more complicated operations which I’ve needed to learn were how to integrate load balancing as well as giving each customer’s instance a custom hostname (things which Kubernetes makes a lot easier).

在使用Kubernetes的过程中，网络的实现方式可以发挥重要作用。 对于初学者来说，了解如何在公共互联网上打开特定系统并隐藏其他数据库(如数据库)，同时保持服务之间的通信非常重要。 我需要学习的一些更复杂的操作是如何集成负载平衡以及如何为每个客户的实例提供自定义的主机名(Kubernetes使事情变得更加容易)。

Kubernetes是否可以解决您当前面临的问题？ ？ (Does Kubernetes solve problems you are currently facing? ?)

If you are not using containers to deploy your application, you probably shouldn’t be using Kubernetes yet. The problems Kubernetes aims to solve are problems that arise when you try and scale a container-based infrastructure.

如果您不使用容器来部署应用程序，那么您可能不应该使用Kubernetes。 Kubernetes旨在解决的问题是尝试扩展基于容器的基础架构时出现的问题。

Here are a few of the problems I think Kubernetes is great at solving when trying to deal with containers at scale.

我认为，在尝试大规模处理容器时，Kubernetes可以很好地解决以下一些问题。

扩大资源 (Scaling up resources)

Kubernetes is basically a cluster of nodes which provide compute resources that can be consumed by container workloads. This clustered architecture allows for a very easy scale-up or scale-down of resources. You just add or a remove nodes from the cluster, and Kubernetes will automatically utilize those resources or reassign workloads on your existing resources.

Kubernetes基本上是节点的集群，这些节点提供可由容器工作负载消耗的计算资源。 这种集群体系结构允许非常轻松地按比例放大或缩小资源。 您只需在集群中添加或删除节点，Kubernetes就会自动利用这些资源或在现有资源上重新分配工作负载。

This solved a major problem I faced, because I went from having a single server I had to keep scaling up (an annoying manual process) to having the ability to scale up or down my infrastructure with a single command using the CLI.

这解决了我面临的一个主要问题，因为我从必须不断扩展(烦人的手动过程)的一台服务器变为能够使用CLI使用单个命令扩展或缩减基础结构的能力。

执行批量更新 (Performing mass updates)

Another problem that Kubernetes solves is the ability to update all your containers. Before, I was writing shell scripts which would pick each relevant container and recreate it using a new image tag. The process would take over an hour, and I had no way of validating that the update was successful. With Kubernetes I was able to perform an update with a single command as in the example below:

Kubernetes解决的另一个问题是能够更新所有容器。 之前，我正在编写shell脚本，该脚本将选择每个相关的容器并使用新的image标签重新创建它。 该过程将花费一个多小时，并且我无法验证更新是否成功。 使用Kubernetes，我可以使用一个命令执行更新，如下例所示：

// Update all the pods of frontend to a new image tag
$ kubectl rolling-update frontend --image=image:v2

Kubernetes also allows you to update any part of Kubernetes (networks, storage, etc.) with commands based on any criteria. This is a huge step up from writing your own scripts to enact changes to your infrastructure.

Kubernetes还允许您使用基于任何条件的命令来更新Kubernetes的任何部分(网络，存储等)。 这是从编写自己的脚本以对基础结构进行更改迈出的一大步。

自我修复 (Self-healing)

The last and one of the most important pieces of Kubernetes I’d like to talk about is the ability to self-heal. If Kubernetes detects something wrong with part of its infrastructure, such as a node not responding or a container not passing its health check, it will perform steps to recreate those parts of itself until things start working again.

我想谈的Kubernetes的最后也是最重要的部分是自我修复的能力。 如果Kubernetes在其基础架构的一部分中检测到问题，例如节点未响应或容器未通过其运行状况检查，它将执行步骤来重新创建其自身的这些部分，直到事情再次开始工作为止。

This is extremely useful because if a piece of the cluster goes down for any reason, the workload will be reassigned and you can even have Kubernetes recreate entire servers to fix the problem.

这是非常有用的，因为如果某个集群中的某个集群由于某种原因而关闭，工作负载将被重新分配，您甚至可以让Kubernetes重新创建整个服务器来解决该问题。

您的应用程序体系结构是否需要改变？ (Will your application architecture need to change??)

When I migrated to Kubernetes, there weren’t that many changes I had to make because it was originally architected to be a multi-instance platform deployed via containers.

当我迁移到Kubernetes时，不需要进行太多更改，因为它最初被设计为通过容器部署的多实例平台。

Here are some of the things I’ve learned while moving my own workload to Kubernetes.

这是我将自己的工作负载转移到Kubernetes时学到的一些东西。

您应用的启动时间很重要 (Startup time of your app is important)

When you create a new deployment, you have to wait for your app to start before it becomes available to the end-user. This becomes a problem if your deployment process involves creating new instances when an end-user presses a button or if you are performing updates on all your customers instances, as that requires a rebuild of the pods.

创建新部署时，必须等待应用程序启动，然后终端用户才能使用它。 如果您的部署过程涉及在最终用户按下按钮时创建新实例，或者您正在对所有客户实例执行更新，则这将成为问题，因为这需要重建Pod。

When moving to Kubernetes you may need to make some changes to your codebase to make the startup process more efficient so the end-user doesn’t have a degraded experience using your product.

迁移到Kubernetes时，您可能需要对代码库进行一些更改，以使启动过程更高效，从而使最终用户在使用产品时不会有降级的体验。

适应多租户架构很困难 (Adapting multi-tenant architectures is difficult)

A multi-tenant architecture means you have a single instance of your application which manages all your end-users in partitioned tenants, usually with a single database being shared between everyone.

多租户架构意味着您拥有一个应用程序实例，该实例管理分区租户中的所有最终用户，通常每个人之间共享一个数据库。

If your application is not built to utilize clustering (multiple servers acting as a single instance) you should not be using Kubernetes yet.

如果您的应用程序未构建为利用集群(多个服务器充当单个实例)，则您不应使用Kubernetes。

Generally I see two types of architectures when working with Kubernetes:

通常，使用Kubernetes时会看到两种类型的架构：

• Multi-instance with one instance of the app for each customer
  为每个客户提供一个应用程序实例的多实例
• Multi-tenant architecture with clustering capabilities as they can utilize scaling up and down resources
  具有集群功能的多租户架构，因为他们可以利用扩展和缩减资源

I personally prefer multi-instance because they are much easier to implement compared to a clustered multi-tenant architecture. Also, the work involved in moving from multi-tenant to multi-instance isn’t too bad compared to adding cluster capabilities to a multi-instance architecture.

我个人更喜欢多实例，因为与群集多租户体系结构相比，它们更容易实现。 而且，与将集群功能添加到多实例体系结构相比，从多租户迁移到多实例的工作还不错。

迁移到无状态应用程序需要花费大量精力 (Moving to a stateless application is a large amount of effort)

One of the great features of Kubernetes is the ability to scale up or down the number of pods in a deployment. But, if your application is not clustered or not stateless, this functionality is wasted since extra pods in a deployment wont be configured properly and can’t be utilized.

Kubernetes的一大特色是能够按比例增加或减少部署中的Pod数量。 但是，如果您的应用程序不是集群的或不是无状态的，则此功能将被浪费，因为部署中的额外Pod将无法正确配置且无法使用。

The process of utilizing statelessness in Kubernetes is often more trouble than it’s worth, since most times you will need to completely rework the way you handle configurations within your application.

在Kubernetes中利用无状态性的过程通常比其应有的麻烦还多，因为大多数时候您将需要完全重做处理应用程序内配置的方式。

Don’t be discouraged if you don’t want to spend the time to make your application stateless or clustered as there are many ways of adapting stateful deployments to use Kubernetes. But those have their own problems which I will not get into in this article.

如果您不想花费时间使应用程序变为无状态或集群状态，请不要气as，因为有许多方法可以使有状态部署适应使用Kubernetes。 但是这些都有其自身的问题，我将不在本文中介绍。

您应该采用Kubernetes吗？ ？ (Should you adopt Kubernetes? ?)

After asking yourself these questions, you should have a pretty good idea if Kubernetes will be a good fit for you at this time. Most early stage startups are probably not going to need it, and more mature ones may have a lot of investment in other technologies so it wouldn’t be feasible to switch.

在问完这些问题之后，您应该非常了解Kubernetes是否现在适合您。 大多数早期阶段的初创公司可能将不再需要它，而更成熟的初创公司可能会在其他技术上投入大量资金，因此进行转换是不可行的。

I think the best case for someone moving to Kubernetes is a startup looking to move from having a Minimum Viable cloud infrastructure that is using containers to power production workloads to something more stable. That was my case, and I can say I went from having periodic downtimes due to resource mismanagement and overworked servers to not having to worry at all about my infrastructure thanks to the power of Kubernetes.

我认为，对于迁移到Kubernetes的人来说，最好的情况是一家初创公司希望从拥有使用容器为生产工作负荷提供动力的最小可行云基础架构转变为更稳定的平台。 这就是我的情况，我可以说我从由于资源管理不善和服务器过度工作而导致的周期性停机到完全不用担心我的基础架构，这要归功于Kubernetes的强大功能。

Looking to connect Kubernetes to your SaaS? Lets talk - ben@servicebot.io

想要将Kubernetes连接到您的SaaS？ 让我们聊聊-ben@servicebot.io

翻译自: https://www.freecodecamp.org/news/how-to-know-if-kubernetes-is-right-for-your-saas-315dfffe0a25/