saas系saas系_您的SaaS的Kubernetes入门
saas系saas系
Kubernetes is a platform to manage and orchestrate your cloud infrastructure. It provides a configuration-driven framework where you can define a few different pieces and with one click get an entire network, disk, and application spun up in a way that’s scalable and easy to manage.
Kubernetes是一个用于管理和协调您的云基础架构的平台。 它提供了一个配置驱动的框架，您可以在其中定义几个不同的部分，并且只需单击一下即可以可扩展且易于管理的方式旋转整个网络，磁盘和应用程序。
Moving your application over to Kubernetes is a high-effort activity if you haven’t designed your app with containers in mind from the start. The goal of this article is to help you on your path towards containerizing your applications with Kubernetes integration in mind.
如果您从一开始就没有考虑到容器的设计，那么将应用程序迁移到Kubernetes是一项艰巨的工作。 本文的目的是帮助您在考虑到Kubernetes集成的情况下实现容器化应用程序。
Be aware that if you try and force your application into Kubernetes without the proper architecture, you will be essentially shooting yourself in the foot by wasting time and accruing technical debt.
请注意，如果您尝试在没有适当架构的情况下将应用程序强制放入Kubernetes中，那么本质上您将浪费时间并增加技术债务，从而陷入困境。
步骤1 —容器化您的应用程序？ (Step 1 — Containerize your application ?)
A container is basically a partitioned section of the operating system that can function as an independent machine. Unlike traditional virtual machines, which rely on a hypervisor to simulate an operating system, containers use a variety of kernel features to provide an environment isolated from the host machine.
容器基本上是操作系统的分区部分，可以充当独立的计算机。 与传统的依靠管理程序来模拟操作系统的虚拟机不同，容器使用各种内核功能来提供与主机隔离的环境。
Containerization is a fairly simple process — using Docker, just define a Dockerfile which lays out the steps needed to install your application on an OS (download packages, install dependencies, and so on).
容器化是一个非常简单的过程-使用Docker，只需定义一个Dockerfile，其中列出了在OS上安装应用程序所需的步骤(下载软件包，安装依赖项等)。
Then, build an image which can be used by developers. More information about the containerization process can be found on Docker’s website.
然后，构建可供开发人员使用的映像。 可以在Docker的网站上找到有关容器化过程的更多信息。
步骤2 –采用多实例架构？ (Step 2 — Adopt a multi-instance architecture ?)
Before you move to Kubernetes, you need to take a hard look at the current way you deliver your application to the end-user.
在转向Kubernetes之前，您需要仔细研究一下将应用程序交付给最终用户的当前方式。
Traditional web applications use a multi-tenant architecture. This means all your users will be sharing a single database instance and a single instance of an application. This can be made to work in Kubernetes — however, I urge you to consider implementing a multi-instance architecture to fully utilize the power of Kubernetes and containerized applications.
传统的Web应用程序使用多租户架构。 这意味着您的所有用户将共享一个数据库实例和一个应用程序实例。 这可以在Kubernetes中起作用，但是，我敦促您考虑实现多实例架构，以充分利用Kubernetes和容器化应用程序的功能。
Some major benefits of adopting a multi-instance architecture are:
采用多实例体系结构的一些主要好处是：
Stability— Instead of a single point of failure (the single application instance), each customer can exist in their own instance. If one instance fails, the others will remain unaffected.
稳定性 -每个客户可以存在于自己的实例中，而不是单个故障点(单个应用程序实例)。 如果一个实例失败，其他实例将不受影响。
Scalability — With a multi-instance architecture, scaling up is a simple matter of adding more resources. However, with a multi-tenant architecture, you could reach a point where you need to come up with a clustered application architecture whose deployment is usually far from trivial.
可伸缩性—在多实例体系结构中，扩展只是增加更多资源的简单问题。 但是，使用多租户体系结构时，您可能需要提出一个集群应用程序体系结构，其部署通常并非易事。
Security — When you are using a single database, all your data lives together. This becomes a major problem in the event of a security breach because all customers’ data can become vulnerable when a single account is compromised. With a multi-instance architecture, only a single customer’s data can be at risk.
安全性 —使用单个数据库时，所有数据都在一起。 在发生安全漏洞的情况下，这将成为一个主要问题，因为当一个帐户遭到破坏时，所有客户的数据都可能变得脆弱。 使用多实例架构，只有单个客户的数据可能会受到威胁。
第3步-确定应用程序的资源消耗⛽ (Step 3— Determine your app’s resource consumption ⛽)
In order to have the most cost-effective infrastructure, you need to pin down how much CPU, memory, and storage are going to be required to run a single instance of your application.
为了拥有最具成本效益的基础架构，您需要确定运行一个应用程序实例所需的CPU，内存和存储空间。
This way, you can set limits so you can get an accurate reading of how much space your Kubernetes nodes need, as well as making sure your nodes aren’t going to become overloaded and unreliable.
这样，您可以设置限制，以便准确了解Kubernetes节点需要多少空间，并确保您的节点不会变得过载和不可靠。
This is usually a trial-and-error process, but you can use a monitoring solution such as Heapster to give a straightforward breakdown of the resources your pods are consuming. This will let you gauge how much to allocate.
这通常是一个反复试验的过程，但是您可以使用诸如Heapster之类的监视解决方案来直接明细您的pod消耗的资源。 这将使您确定要分配多少。
After you figure out your resource allocation, you can calculate optimal server sizes for your Kubernetes nodes so you get the most bang for your buck.
确定资源分配后，您可以为Kubernetes节点计算最佳服务器大小，从而最大程度地节省成本。
You take the memory or CPU each instance needs to function, and multiply it by 100 (the maximum number of pods a node can hold). This will give you a ballpark estimate of how much memory/CPU your nodes should have.
您将每个实例所需的内存或CPU占用，然后乘以100(节点可容纳的Pod的最大数量)。 这将使您对节点应该具有多少内存/ CPU进行估算。
Still, you should always stress test your application to ensure it runs smoothly when the node fills up.
尽管如此，您仍应始终对应用程序进行压力测试，以确保当节点填满时它可以平稳运行。
步骤4 —与Kubernetesnet️集成 (Step 4— Integrate with Kubernetes ⚙️)
Once your Kubernetes cluster is up and running, there are a lot of DevOps practices you can begin developing to make your life easier. Some of these integration points take the following forms:
一旦您的Kubernetes集群启动并运行，您可以开始开发许多DevOps实践，以使您的生活更轻松。 其中一些集成点采用以下形式：
自动缩放Kubernetes节点 (Automatic scaling of Kubernetes nodes)
When your nodes become full, generally you want to provision more nodes so everything can keep chugging along smoothly. One way you can do this is with a tool like kops.
当节点变满时，通常您希望配置更多的节点，以便所有内容都能顺畅运行。 一种实现方法是使用kops之类的工具。
自动缩放应用程序 (Automatic scaling of applications)
Some applications will need to be scaled up or down based on the current usage. Kubernetes provides this function out of the box using triggers which automatically scale deployments. For example, running this command:
某些应用程序将需要根据当前使用情况按比例放大或缩小。 Kubernetes通过使用触发器自动提供扩展功能来提供此功能。 例如，运行以下命令：
kubectl autoscale deployment myapp --cpu-percent=50 --min=1 --max=10will set the myapp deployment to scale up to 10 pods when the CPU percentage goes above 50.
将在CPU百分比超过50时将myapp部署设置为最多扩展10个容器。
根据用户操作自动配置实例 (Automatic provisioning of instances upon user action)
For a multi-instance architecture, end-users will ultimately be requesting applications be deployed in Kubernetes. To provide this, you should be looking at integrating your app with the Kubernetes API, or using a third-party solution such as ServiceBot to provide a portal to request instances.
对于多实例架构，最终用户最终将要求在Kubernetes中部署应用程序。 为此，您应该考虑将您的应用程序与Kubernetes API集成，或者使用第三方解决方案(例如ServiceBot)来提供请求实例的门户。
通过用户操作定义自定义主机名 (Custom Hostname definition by user action)
A growing trend lately has been end-users attaching their domain to applications. Kubernetes has tools in place to make this process easier and even get to the point where it becomes self-service (users pressing a button to get their domain pointing to the pod). You can use a system such as Nginx Ingress to accomplish this.
最近的增长趋势是最终用户将其域附加到应用程序。 Kubernetes提供了一些工具来简化此过程，甚至使其成为自助服务(用户按下按钮以使其域指向Pod)。 您可以使用Nginx Ingress之类的系统来完成此任务。
结论 (Conclusion)
Kubernetes is a great way to manage your cloud infrastructure. If you are in a position where you are having trouble scaling your application, consider moving to a Kubernetes-based architecture. You will see a large increase in your DevOps productivity when it comes to deployments, clustering, and overall stability.
Kubernetes是管理您的云基础架构的好方法。 如果您无法扩展应用程序，请考虑迁移到基于Kubernetes的架构。 当涉及到部署，集群和整体稳定性时，您将发现DevOps生产率大大提高。
ServiceBot is a platform that helps you manage your SaaS by automating billing, deployments, and your sales pipeline.
ServiceBot 是一个平台，可通过自动化计费，部署和销售渠道来帮助您管理SaaS。
您是否要扩大您的SaaS？ 让我们谈谈 。 (Are you looking to scale up your SaaS? Let’s talk.)
翻译自: https://www.freecodecamp.org/news/getting-started-with-kubernetes-for-your-saas-91e91116dd7d/
saas系saas系