托管非托管
by Daniele Polencic
由Daniele Polencic
如何利用Kubernetes的力量来优化您的托管成本 (How to leverage the power of Kubernetes to optimise your hosting costs)
During the last few years, the industry has experienced a shift towards developing smaller and more focused applications.
在过去的几年中，该行业经历了向开发更小，更集中的应用程序的转变。
It doesn’t come as a surprise that more and more companies are breaking their massive and static monoliths into a set of decoupled and independent components.
越来越多的公司将其庞大的静态整体分解为一组相互分离且独立的组件不足为奇。
And rightly so.
是的。
Services that are tiny in size are:
规模很小的服务是：
quicker to deploy — because you create and release them in smaller chunks
部署更快 -因为您可以较小的块创建和发布它们
easier to iterate on — since adding features happens independently
易于迭代 -因为添加功能独立发生
resilient — the overall service can still function despite one of the components not being available
弹性 —尽管其中一个组件不可用，但总体服务仍然可以运行
Smaller services are excellent from a product and development perspective.
从产品和开发的角度来看，较小的服务是出色的。
But how does that cultural shift impact the infrastructure?
但是这种文化转变如何影响基础设施？
大规模管理基础架构 (Managing infrastructure at scale)
It turns out that things are rather simple when you deal with a few sparse applications.
事实证明，在处理一些稀疏应用程序时，事情非常简单。
You can count them with your hands, and you have plenty of time to dedicate to support and release.
您可以用手数数它们，并且您有足够的时间专门用于支持和释放。
In a large organisation, managing hundreds of applications is demanding, but still doable. You have several teams dedicated to developing, packaging and releasing applications.
在大型组织中，管理数百个应用程序是很困难的，但仍然可行。 您有几个团队致力于开发，打包和发布应用程序。
Developing services out of smaller components, on the other hand, introduces a different challenge.
另一方面，使用较小的组件开发服务会带来不同的挑战。
When for every application, you can refactor the same apps in a collection of four components, you have at least four times more apps to develop, package and release.
当对于每个应用程序，您可以在四个组件的集合中重构相同的应用程序时，您要开发，打包和发布的应用程序至少多四倍。
It’s not uncommon for a small service to be made out of a dozen components such as a front-end app, a backend API, an authorisation server, an admin application, etc.
小型服务由十几个组件组成，例如前端应用程序，后端API，授权服务器，管理应用程序等，这并不少见。
Indeed when you develop services that interact with each other, you see an explosion of components deployed on your infrastructure.
确实，当您开发相互交互的服务时，会看到部署在基础架构上的组件数量激增。
It gets harder, though.
不过，它变得越来越难。
您可能会浪费金钱在计算资源上 (You’re probably wasting your money on compute resources)
Most of the services are deployed to virtual machines such as Amazon EC2, Digital Ocean Droplets or Azure Virtual Machines.
大多数服务已部署到虚拟机，例如Amazon EC2，Digital Ocean Droplets或Azure虚拟机。
Each virtual machine comes with an operating system that consumes part of the memory and CPU resources allocated to it.
每个虚拟机都带有一个操作系统，该操作系统消耗分配给它的部分内存和CPU资源。
When you create a 1GB of memory and 1 vCPU droplet on Digital Ocean, you end up using 700MB in memory and 0.8 vCPU after you remove the overhead of the operating system.
当您在Digital Ocean上创建1GB内存和1个vCPU Droplet时，除去操作系统的开销后，最终将使用700MB内存和0.8 vCPU。
Or in other words, for every fifth virtual machine, the overhead adds up to a full virtual machine.
换句话说，对于每五分之一的虚拟机，开销总计为一个完整的虚拟机。
You pay for five but can use only four.
您需要支付五笔费用，但只能使用四笔。
You can’t escape from it, even if you’re on bare metal.
即使您处于裸机状态，也无法逃脱。
You still need to run your services from a base operating system.
您仍然需要从基本操作系统运行服务。
It’s okay, everybody needs to run an operating system — you say.
没关系，每个人都需要运行一个操作系统 -您说。
And you’re right.
而且你是对的。
However, the cash wasted on operating systems is only the tip of the iceberg.
但是，浪费在操作系统上的现金只是冰山一角。
您还浪费了大量资源利用率 (You’re also wasting A LOT of money on resource utilisation)
You have probably realised that when you break your services into smaller components, each of them comes with different resource requirements.
您可能已经意识到，将服务分解为较小的组件时，每个组件都有不同的资源要求。
Some components such as data processing and data mining applications are CPU intensive. Others, such as servers for real-time applications might use more memory than CPU.
诸如数据处理和数据挖掘应用程序之类的某些组件占用大量CPU。 其他服务器(例如用于实时应用程序的服务器)使用的内存可能比CPU多。
Amazon Web Services and the other cloud providers have indeed a long list of compute resources that fit every need: general purpose, CPU optimised, memory optimised, storage optimised and GPU computing.
Amazon Web Services和其他云提供商确实拥有满足各种需求的一长串计算资源：通用，CPU优化，内存优化，存储优化和GPU计算。
You should strive to use the right virtual machine for your component. Ideally, it should match the memory consumption and CPU utilisation.
您应该努力为组件使用正确的虚拟机。 理想情况下，它应该与内存消耗和CPU使用率相匹配。
Are you working on a critical web component written in Java?
您是否正在使用Java编写关键的Web组件？
Perhaps you should use a c5.4xlarge optimised for compute-intensive workloads.
也许您应该使用针对计算密集型工作负载优化的c5.4xlarge。
The closer you match the requirements, the better you’re utilising your resources.
您与需求越接近，就越能充分利用您的资源。
In practice, this is somewhat uncommon, though.
在实践中，这种情况并不常见。
Should you use a c5.2xlarge or a c5.4xlarge?
您应该使用c5.2xlarge还是c5.4xlarge？
Does the next tier (8 vCPU and 16GB memory) make a difference?
下一层(8个vCPU和16GB内存)是否有所不同？
It’s much easier to select a couple of computing profiles that are good enough in 80% of the cases and use those for all components.
选择几个在80％的情况下都足够好的计算概要文件并将其用于所有组件要容易得多。
In fact, what’s wrong with using mostly the same virtual machine for every workload?
实际上，为每个工作负载使用几乎相同的虚拟机怎么了？
Nothing at all, if you’re happy to wrap every component into a 2GB of memory and vCPU compute capacity.
如果您愿意将每个组件包装到2GB的内存和vCPU计算容量中，那什么都没有。
Even if your component can run with only 1GB of memory.
即使您的组件只能以1GB的内存运行。
Yes, you could optimise in the future.
是的，您将来可以进行优化。
But let’s be honest: it’s like changing tires while driving.
但是说实话： 就像开车时换轮胎一样 。
You put a lot of effort into tuning the system only to realise that the application changed again and you have to start from scratch.
您付出了很大的努力来调整系统，只是为了意识到应用程序再次发生了更改，您必须从头开始。
So you end up taking the only sensible choice: selecting a small, medium and large profile for virtual machines and using them for all workloads.
因此，您最终只能做出明智的选择：为虚拟机选择一个小型，中型和大型配置文件，并将其用于所有工作负载。
You know you have to live with wasting hundreds of megabytes of RAM and plenty of CPU cycles.
您知道必须忍受浪费数百兆的RAM和大量的CPU周期。
If it makes you feel any better, there are plenty of companies suffering from similar inefficiencies.
如果让您感觉更好，那么很多公司都会遭受类似的效率低下之苦。
Some utilise as little as 10% of the allocated resources.
有些仅使用分配资源的10％。
You pay $1000 in EC2 instances on Amazon, you only actually use $100 of it.
您在Amazon上的EC2实例中支付了1000美元，而实际上只使用了其中的100美元。
That doesn’t sound like the best way to spend your budget.
听起来这不是花费预算的最佳方法。
You should get your money back on the resources you don’t use.
您应该将您不使用的资源退还给您。
But why are those requirements so different anyway?!
但是，为什么这些要求仍然如此不同？
选择正确的工具弊大于利 (When choosing the right tool does more harm than good)
When developers have the freedom to use the right tool for the job they usually go wild.
当开发人员有自由使用正确工具进行工作时，他们通常会发疯。
Node.js for the front-end, Spring Boot for the backend API, Flask and Celery for the processing background jobs, React.js for the client-side, you name it.
您可以命名前端的Node.js，后端API的Spring Boot，处理后台作业的Flask和Celery，客户端的React.js。
The infrastructure becomes a theme park, hundreds of applications running on entirely different runtimes.
基础设施成为主题公园，数百个应用程序在完全不同的运行时上运行。
Having the right technology for the job enables greater iteration speed, but it usually comes with the extra burden of managing one more programming language.
拥有适合这项工作的技术可以提高迭代速度，但是通常会带来额外的负担，即需要管理另一种编程语言。
While you could mitigate the proliferation of tools and languages, in practice, it’s more complicated than that.
尽管您可以减轻工具和语言的泛滥，但实际上，这要复杂得多。
Two applications sharing the same JVM runtime might rely on a different set of dependencies and libraries.
共享相同JVM运行时的两个应用程序可能依赖于一组不同的依赖项和库。
Perhaps one relies on ImageMagick to resize images.
也许有人依靠ImageMagick来调整图像大小。
The other relies on a binary such as PhantomJS or ZeroMQ to be available in its path.
另一个依赖于二进制文件(例如PhantomJS或ZeroMQ)可在其路径中使用。
You should package those dependencies alongside its application.
您应该将那些依赖项与应用程序一起打包。
And so you end up dealing with dozens of configurations that are the same, but different in their unique way.
因此，您最终要处理许多相同但不同的独特配置。
You shouldn’t treat the infrastructure as an afterthought. You should look after your dependencies and package them as you develop the application, right from the beginning.
您不应将基础架构视为事后的想法。 您应该从一开始就照顾好依赖项并在开发应用程序时将其打包。
Ideally, you should archive all of the parts necessary to run your component as a single bundle.
理想情况下，您应该将将组件作为一个捆绑包运行所需的所有零件都存档。
No more getting lost in chasing dependencies just before a release.
在发布之前，不再有追逐依赖项的迷路了。
Yes, easier said than done.
是的，说起来容易做起来难。
Or maybe not.
或者可能不是。
从航运业借用集装箱 (Borrowing containers from the shipping industry)
Information technology is not the only industry with the same problem.
信息技术并不是唯一一个存在同样问题的行业。
Shipping goods in cargo around the globe is hard when you need to store items individually.
当您需要单独存储物品时，很难在全球范围内运输货物。
Imagine having thousands of boxes of all shapes and sizes to store in the hold. You should pay extra attention to how you pack the items because you don’t want to miss one when it’s time to unload.
想象一下，有成千上万个各种形状和大小的盒子要存放在货舱中。 您应该特别注意物品的包装方式，因为您不想在卸货时错过任何物品。
The cargo industry came up with a solution: containers.
货运业提出了一个解决方案：集装箱。
The cargo company doesn’t carry goods; it ships containers.
货运公司不运载货物； 它运送集装箱。
Do you want to ship all your goods safely? Place them in a container. When the container is unloaded, you’re guaranteed to have everything there.
您想安全运送所有货物吗？ 将它们放在容器中。 卸下集装箱后，可以保证在这里有所有东西。
You can apply the same principle to your applications.
您可以将相同的原理应用于您的应用程序。
Do you want to deploy your application and all its dependency safely?
您是否要安全地部署应用程序及其所有依赖项？
Wrap them into a Linux container.
将它们包装到Linux容器中。
A Linux container is a like a cargo container, but it encapsulates all files, binaries, and libraries necessary to run your process.
Linux容器就像一个货运容器，但是它封装了运行过程所需的所有文件，二进制文件和库。
Doesn’t that sound a lot like virtual machines?
这听起来不像虚拟机吗？
节食的虚拟机 (Virtual machines on a diet)
Indeed, if you squint and look from afar at virtual machines, they resemble containers.
确实，如果您斜视并从远处看虚拟机，它们就像容器。
They encapsulate the application and its dependencies like containers.
它们像容器一样封装应用程序及其依赖项。
However, virtual machines are slow to start, usually larger and — as you learnt — a waste of resources.
但是，虚拟机的启动速度很慢，通常会更大，并且-如您所知-浪费资源。
In fact, you have to allocate a fixed number of CPU and memory to run your application.
实际上，您必须分配固定数量的CPU和内存才能运行您的应用程序。
They also have to emulate hardware and come with the extra baggage of an operating system.
他们还必须模拟硬件，并附带操作系统的额外负担。
Linux containers, on the other hand, are merely processes running on your host.
另一方面，Linux容器仅仅是在主机上运行的进程。
Indeed, for the same operating system and server, you could have dozens of containers running on that host.
实际上，对于相同的操作系统和服务器，您可以在该主机上运行数十个容器。
And despite living on the same computer, processes running in containers can’t see each other.
尽管位于同一台计算机上，但是在容器中运行的进程却无法相互看到。
Applications running inside containers are entirely isolated and can’t tell the difference between a virtual machine and a container.
在容器内运行的应用程序是完全隔离的，无法分辨虚拟机和容器之间的区别。
That’s great news!
这真是个好消息！
Linux containers are like virtual machines, but more efficient.
Linux容器就像虚拟机一样，但是效率更高。
But what are those Linux containers made of, anyway?
但是，那些Linux容器是由什么制成的？
Linux容器是具有优势的隔离进程 (Linux containers are isolated processes with benefits)
The magic of containers comes from two features in the Linux kernel: control groups and namespaces.
容器的神奇之处来自Linux内核中的两个功能：控制组和名称空间。
Control groups are a convenient way to limit the CPU or memory that a particular process can use.
控制组是限制特定进程可以使用的CPU或内存的便捷方法。
As an example, you could say that your component should use only 2GB of memory and one of your four CPU cores.
例如，您可以说您的组件应仅使用2GB内存和四个CPU内核之一。
Namespaces, on the other hand, are in charge of isolating the process and limiting what it can see.
另一方面，命名空间负责隔离过程并限制其可见内容。
The component can only see the network packets that are directly related to it. It won’t be able to see all of the network packets flowing through the network adapter. Control groups and namespaces are low-level primitives.
该组件只能看到与其直接相关的网络数据包。 它将无法查看所有流经网络适配器的网络数据包。 控制组和名称空间是低级原语。
With time, developers created more and more layers of abstractions to make it easier to control those kernel features.
随着时间的流逝，开发人员创建了越来越多的抽象层，从而使控制这些内核功能变得更加容易。
One of the first abstractions was LXC, but the real deal was Docker that was released in 2013.
最早的抽象方法之一是LXC，但真正的交易是2013年发布的Docker。
Docker not only abstracts the above kernel features but it is pleasant to work with.
Docker不仅抽象了上述内核功能，而且使用起来很愉快。
Running a Docker container is as simple as:
运行Docker容器非常简单：
docker run <my-container>And since all containers implement a standard interface, you can run any other container with the same command:
并且由于所有容器都实现了标准接口，因此您可以使用相同的命令运行任何其他容器：
docker run mysqlAnd you have a MySQL database.
并且您有一个MySQL数据库。
Portability of the application and a standard interface to create and run processes is what makes containers so popular.
应用程序的可移植性以及用于创建和运行进程的标准接口使容器如此流行。
Containers are great!
容器很棒！
- You saved money on running dozens of operating systems ✅ 您节省了运行数十个操作系统的费用✅
- You packaged applications as portable units ✅ 您已将应用程序打包为便携式单元✅
- You have a proliferation of containers ❌ 您有大量的容器❌
It sounds like containers haven’t solved all problems after all.
听起来容器毕竟还没有解决所有问题。
You need a way to manage containers.
您需要一种管理容器的方法。
大规模管理容器 (Managing containers at scale)
When you have hundreds if not thousands of containers, you should find a way to run multiple containers on the same server. And you should plan for containers to be spread on multiple servers too.
当拥有数百个甚至数千个容器时，应该找到一种在同一服务器上运行多个容器的方法。 而且，您还应该计划将容器分布在多台服务器上。
So you can distribute the load across several nodes and prevent that a single failure could take down the entire service.
因此，您可以将负载分布在多个节点上，并防止单个故障可能导致整个服务中断。
Keeping track of where every container is deployed in your infrastructure doesn’t sound like the best use of your time.
跟踪每个容器在您的基础架构中的部署位置听起来并不像是您最好地利用时间。
Perhaps there’s a way to automate it?
也许有一种自动化的方法？
And what if you could have an algorithm deciding where to place those containers too?
而且，如果您可以使用一种算法来决定将那些容器放置在哪里呢？
Perhaps it could be so smart to pack containers efficiently so to maximise server density. Maybe even keep a list of deployed containers and their host.
有效地包装容器以最大化服务器密度也许是那么聪明。 甚至可以保留已部署容器及其主机的列表。
It turns out that someone had precisely that idea and came up with a solution.
事实证明，有人完全有这个想法，并提出了解决方案。
Kubernetes，强大的容器协调器 (Kubernetes, the mighty container orchestrator)
Kubernetes was initially a Google creation.
Kubernetes最初是Google的创作。
Google was running a technology similar to containers and had to find an efficient way to schedule workloads.
Google正在运行类似于容器的技术，因此必须找到一种有效的方式来安排工作量。
They didn’t want to keep and manually update a long list of containers and servers. So they decided to write a platform that could automatically analyse resource utilisation, schedule and deploy containers.
他们不想保留并手动更新一长串的容器和服务器。 因此，他们决定编写一个可以自动分析资源利用，调度和部署容器的平台。
But it was closed source.
但这是封闭源。
A few Googlers decided to rewrite the platform as an open source effort. And the rest is history.
一些Google员工决定将其改写为开放源代码。 剩下的就是历史。
So what’s Kubernetes?
那么什么是Kubernetes？
You can think of Kubernetes as a scheduler.
您可以将Kubernetes视为调度程序。
Kubernetes inspects your infrastructure (bare metal or cloud, public or private) and measures CPU and memory for each computer.
Kubernetes检查您的基础架构(裸机或云，公共或私有)，并测量每台计算机的CPU和内存。
When you request to deploy a container, Kubernetes identifies the memory requirements for your container and finds the best server that satisfies your request.
当您请求部署容器时，Kubernetes会确定容器的内存要求，并找到满足您要求的最佳服务器。
You don’t decide where the application is deployed. The data centre is abstracted away from you.
您不确定应用程序的部署位置。 数据中心远离您。
In other words, Kubernetes will play Tetris with your infrastructure.
换句话说，Kubernetes将在您的基础架构上玩俄罗斯方块。
Docker containers are the blocks, servers are the boards, and Kubernetes is the player.
Docker容器是块，服务器是板，而Kubernetes是播放器。
Having Kubernetes efficiently packing your infrastructure means that you get more computing for your money. You can do a lot more with a lot less.
Kubernetes有效地打包您的基础架构意味着您可以花更多钱获得更多的计算能力。 您可以事半功倍。
And your overall bill usage should decrease as a result of that.
因此，您的总帐单使用量应减少。
Remember the companies using only 10% of their allocated resource?
还记得公司仅使用其分配资源的10％吗？
Well, Kubernetes just saved your day.
好吧，Kubernetes拯救了您的一天。
But there’s more.
但是还有更多。
Kubernetes has a killer feature that’s usually forgotten or dismissed.
Kubernetes具有通常被遗忘或忽略的杀手级功能。
Kubernetes作为数据中心上的API层 (Kubernetes as an API layer over your data centre)
Everything you do in Kubernetes is one API call away from you.
您在Kubernetes中所做的一切都离您一个API调用。
Do you need to deploy a container? There’s a REST endpoint for that.
您是否需要部署容器？ 有一个REST端点。
Perhaps you wish to provision a load balancer? Not a problem. Just call this API.
也许您希望提供一个负载均衡器？ 没问题 只需调用此API。
Do you wish to provision storage? Please send a POST request to this URL.
您要配置存储空间吗？ 请发送POST请求到该URL。
Everything you do in Kubernetes is calling APIs.
您在Kubernetes中所做的一切都在调用API。
And there are plenty of good reasons to be excited about that:
对此有很多充分的理由感到兴奋：
- You can create scripts and daemons that interact with the API programmatically 您可以创建以编程方式与API交互的脚本和守护程序
- The API is versioned; when you upgrade your cluster you can keep using the old API and gradually migrate API已版本化； 升级群集时，您可以继续使用旧的API并逐步迁移
- You can install Kubernetes in any cloud provider or data centre, and you can leverage the same API 您可以在任何云提供商或数据中心中安装Kubernetes，并且可以利用相同的API
You can think of Kubernetes as a layer on top of your infrastructure.
您可以将Kubernetes视为基础架构之上的一层。
And since this layer is generic and it can be installed anywhere, you can always take it with you.
由于该层是通用层，可以安装在任何地方，因此您可以随时随身携带。
Amazon Web Services is too expensive?
Amazon Web Services太贵了吗？
No problemo.
没问题。
You can install Kubernetes on Google Cloud Platform and move your workloads there.
您可以在Google Cloud Platform上安装Kubernetes并将工作负载移到那里。
Or perhaps you can keep both because having a strategy for high availability always comes in handy.
也许您可以同时保留两者，因为拥有高可用性策略总是很方便的。
But maybe you don’t believe me.
但是也许你不相信我。
It’s too good to be true, and I’m selling smoke and mirrors.
真是太好了，我在卖烟和镜子。
Let me show you.
让我给你演示。
使用Kubernetes节省您的云账单 (Saving on your cloud bill with Kubernetes)
Netlify is a platform for building, deploying, and managing static websites.
Netlify是一个用于构建，部署和管理静态网站的平台。
It has its own CI pipeline, so every time you push a change to a repository, your website is rebuilt.
它具有自己的CI管道，因此，每次将更改推送到存储库时，都会重建您的网站。
Netlify managed to migrate to Kubernetes, double their user base, but still maintained the costs unchanged.
Netlify设法迁移到Kubernetes，使用户群翻了一番，但仍保持了成本不变。
That’s great news!
这真是个好消息！
Imagine saving 50% of your Google Cloud Platform bill!
想象一下，节省了50％的Google Cloud Platform账单！
But Netlify isn’t the only one.
但是Netlify并不是唯一的一家。
Qbox — a company that focuses on hosted Elastic Search — managed to save again 50% per month on AWS bills!
专注于托管Elastic Search的公司Qbox设法每月再次节省50％的AWS账单！
In the process, they also open sourced their efforts in multi-cloud operations.
在此过程中，他们还将多云操作的工作开源 。
If you’re still not impressed, you should check out the press made by OpenAI.
如果您仍然不满意，则应查看OpenAI的新闻报道。
OpenAI is a non-profit research company that focuses on artificial intelligence and machine learning. They wrote an algorithm to play the multi player online game Dota as any human player would.
OpenAI是一家致力于人工智能和机器学习的非营利性研究公司。 他们编写了一种算法，可以像任何人类玩家一样玩多人在线游戏Dota。
But they went the extra step and trained a team of machines to play together.
但是他们又走了一步，训练了一组机器一起玩。
And they used Kubernetes to scale their machine learning model in the cloud.
他们使用Kubernetes在云中扩展其机器学习模型。
Wondering the details of their cluster?
想知道集群的详细信息吗？
128000 vCPUs
128000个vCPU
That’s about 16000 MacBook Pros.
大约是16000台MacBook Pro。
256 Nvidia Tesla P100
256英伟达Tesla P100
That’s 2100 Teraflops 16-bit floating-point performance.
那就是2100 Teraflops的16位浮点性能。
The same as you’d run 525 PlayStation 4s.
与您运行525 PlayStation 4s相同。
Can you guess the cost per hour?
你能猜出每小时的费用吗？
No?
没有？
Only $1280/hr for 128000 vCPU and $400 for the 256 Nvidia P100.
128000 vCPU仅需$ 1280 /小时，而256 Nvidia P100仅需$ 400。
That’s not a lot considering that winning Dota tournaments could net you prizes in the order of millions of dollars.
考虑到赢得Dota锦标赛可以为您带来数百万美元的奖金，这并不是很多。
So, what are you waiting for?
那你还在等什么？
Get ready to adopt Kubernetes and save on your cloud bill!
准备采用Kubernetes并节省您的云费用！
最后的笔记 (Final notes)
Kubernetes and containers are here to stay.
Kubernetes和容器仍在这里。
With backing from companies such as Google, Microsoft, Red Hat, Pivotal, Oracle, IBM, and many more it’s hard to believe that it won’t catch on.
在Google，Microsoft，Red Hat，Pivotal，Oracle，IBM等公司的支持下，很难相信它不会流行。
Many companies are getting a head start on Kubernetes and joining the revolution.
许多公司在Kubernetes上取得了领先，并加入了这场革命。
Not just startups and SMEs, but big corporations such as banks, financial institutions and insurance companies are betting on containers and Kubernetes to be the future.
不仅是初创企业和中小型企业，而且银行，金融机构和保险公司等大公司也将集装箱和Kubernetes押注为未来。
Even companies invested in the Internet of Things and embedded systems.
甚至公司也投资了物联网和嵌入式系统。
It’s still early days and the community has time to mature, but you should keep a close eye on the innovation in this space.
现在还处于初期，社区还有时间成熟，但是您应该密切关注这一领域的创新。
那是所有人！ (That’s all folks!)
Many thanks to Andy Griffiths, John Topley and Walter Miani for reading a draft of this post and offering some invaluable suggestions.
非常感谢Andy Griffiths ， John Topley和Walter Miani阅读本文的草稿并提供了一些宝贵的建议。
If you enjoyed this article, you might find interesting reading:
如果您喜欢这篇文章，可能会发现有趣的阅读内容：
Getting started with Docker and Kubernetes on Windows 10 where you’ll get your hands dirty and install Docker and Kubernetes in your Windows environment.
在Windows 10上使用Docker和Kubernetes入门，在这里您会手忙脚乱并在Windows环境中安装Docker和Kubernetes。
3 simple tricks for smaller Docker images. Docker images don’t have to be large. Learn how to put your Docker images on a diet!
较小的Docker映像的3个简单技巧 。 Docker镜像不必很大。 了解如何精简Docker映像！
成为在Kubernetes中部署和扩展应用程序的专家 (Become an expert at deploying and scaling applications in Kubernetes)
Get a head start with our hands-on courses and learn how to master scalability in the cloud.
首先参加我们的动手课程，并学习如何掌握云中的可伸缩性。
Learn how to:
了解如何：
- Handle the busiest traffic websites without breaking a sweat 轻松处理最繁忙的交通网站
- Scale your jobs to thousands of servers and reduce the waiting time from days to minutes 将您的工作扩展到数千台服务器，并将等待时间从几天减少到几分钟
- Enjoy peace of mind knowing that your apps are highly available with a multi-cloud setup 知道您的应用程序在多云设置下高度可用，让您高枕无忧
- Save ton of cash on your cloud bill by using only the resources your need 仅使用您需要的资源即可在云账单上节省大量现金
- Supercharge your delivery pipeline and deploy application around the clock 增强您的交付管道并全天候部署应用程序
Become an expert in Kubernetes →
The article was originally published at learnk8s.io
该文章最初发表在learnk8s.io
托管非托管
322
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
