{"id":80076,"date":"2020-05-03T01:42:34","date_gmt":"2020-05-02T23:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt"},"modified":"2020-05-03T01:42:34","modified_gmt":"2020-05-02T23:42:34","slug":"proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt","title":{"rendered":"Designing Kubernetes Clusters: How Many Should There Be?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Note: translation.<\/b>: This material is from an educational project <noindex><a rel=\"nofollow\" href=\"https:\/\/learnk8s.io\/\">learnk8s<\/a><\/noindex> \u2014 the answer to a common question when designing infrastructure based on Kubernetes. We hope that sufficiently detailed descriptions of the pros and cons of each option will help you make an optimal choice for your project.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Designing Kubernetes Clusters: How Many Should There Be?\" src=\"\/wp-content\/uploads\/2020\/05\/d3cc3b7e686e39032b1f02f3e8b6c46c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>TL;DR<\/b>the same set of workloads can be run on several large clusters (each cluster will bear a large number of workloads) or on many smaller ones (with a small number of workloads in each cluster).<\/p>\n<p>Below is a table assessing the pros and cons of each approach:<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><img decoding=\"async\" alt=\"Designing Kubernetes Clusters: How Many Should There Be?\" src=\"\/wp-content\/uploads\/2020\/05\/ab5b5fefc97c3befddbaeb0791f8a90d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWhen using Kubernetes as a platform for application deployment, several fundamental questions often arise about the intricacies of cluster configuration:<\/p>\n<ul>\n<li> <i>How many clusters should be employed?<\/i><\/li>\n<li> <i>How large should they be?<\/i><\/li>\n<li> <i>What should each cluster include?<\/i><\/li>\n<\/ul>\n<p>\nIn this article, I will attempt to answer all these questions by analyzing the pros and cons of each approach.<\/p>\n<h2>Framing the Question<\/h2>\n<p>\nAs a software creator, you are likely developing and deploying multiple applications in parallel.<\/p>\n<p>Moreover, many instances of these applications are probably running in various environments \u2014 for instance, these could be <i>dev<\/i>, <i>test<\/i> and <i>prod<\/i>.<\/p>\n<p>As a result, you end up with a whole matrix of applications and environments:<\/p>\n<p><img decoding=\"async\" alt=\"Designing Kubernetes Clusters: How Many Should There Be?\" src=\"\/wp-content\/uploads\/2020\/05\/f2a811fa82e1e433463ba25d29f837e6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Applications and Environments<\/i><\/p>\n<p>In the example above, there are 3 applications and 3 environments, resulting in 9 possible combinations.<\/p>\n<p>Each application instance represents a self-sufficient deployment unit that can be worked with independently of others.<\/p>\n<p><i>Note that <b>application instance<\/b> may consist of multiple <b>components<\/b>, such as frontend, backend, database, etc. In the case of a microservices application, the instance will include all microservices.<\/i><\/p>\n<p>As a result, Kubernetes users have several questions:<\/p>\n<ul>\n<li> Should all instances of an application be placed in one cluster?<\/li>\n<li> Should a separate cluster be created for each application instance?<\/li>\n<li> Or, perhaps, should a combination of the above approaches be used?<\/li>\n<\/ul>\n<p>\nAll these options are quite viable since Kubernetes is a flexible system that doesn't limit the user's choices.<\/p>\n<p>Here are some possible paths:<\/p>\n<ul>\n<li> one large shared cluster;<\/li>\n<li> multiple small specialized clusters;<\/li>\n<li> one cluster for each application;<\/li>\n<li> one cluster for each environment.<\/li>\n<\/ul>\n<p>\nAs shown below, the first two approaches are at opposite ends of the spectrum:<\/p>\n<p><img decoding=\"async\" alt=\"Designing Kubernetes Clusters: How Many Should There Be?\" src=\"\/wp-content\/uploads\/2020\/05\/99b8fd0d1e4173705e7996cf8ccb6eec.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>From a few large clusters (on the left) to many small ones (on the right)<\/i><\/p>\n<p><i>In general, one cluster is considered 'larger' than another if it has more nodes and pods. For example, a cluster with 10 nodes and 100 pods is larger than a cluster with 1 node and 10 pods.<\/i><\/p>\n<p>Well, let's get started!<\/p>\n<h2>1. One large shared cluster<\/h2>\n<p>\nThe first option is to deploy all workloads in a single cluster:<\/p>\n<p><img decoding=\"async\" alt=\"Designing Kubernetes Clusters: How Many Should There Be?\" src=\"\/wp-content\/uploads\/2020\/05\/283fc3c3f5ccb40a157ccff600628114.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>One large cluster<\/i><\/p>\n<p>Within this approach, the cluster serves as a universal <b>infrastructure platform<\/b> \u2014 everything you need can simply be deployed in the existing Kubernetes cluster.<\/p>\n<p><i><noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/overview\/working-with-objects\/namespaces\/\">Namespaces<\/a><\/noindex> Kubernetes allows for logical separation of parts of the cluster, so each instance of an application can use its own namespace.<\/i><\/p>\n<p><i>Let's look at the pros and cons of this approach.<\/i><\/p>\n<h3>+ Efficient resource utilization<\/h3>\n<p>\nIn the case of a single cluster, only one copy of all resources necessary to start and manage the Kubernetes cluster is required.<\/p>\n<p>For example, this is true for master nodes. Typically, each Kubernetes cluster has about 3 master nodes, so for a single cluster, this number will remain the same (in comparison, 10 clusters will require 30 master nodes).<\/p>\n<p>This nuance also applies to other services operating at the cluster-wide level, such as load balancers, Ingress controllers, authentication, logging, and monitoring systems.<\/p>\n<p>In a single cluster, all these services can be utilized at once for all workloads (there is no need to create copies as in the case of multiple clusters).<\/p>\n<h3>+ Cost-effectiveness<\/h3>\n<p>\nAs a result of the above, fewer clusters typically cost less because there are no redundant resource expenses.<\/p>\n<p>This is especially true for master nodes, which can be quite costly regardless of the hosting method (on-premises or in the cloud).<\/p>\n<p>Some managed Kubernetes services, such as <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/kubernetes-engine\">Google Kubernetes Engine (GKE)<\/a><\/noindex> or <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.microsoft.com\/en-us\/azure\/aks\/\">Azure Kubernetes Service (AKS)<\/a><\/noindex>, providing a management layer for free. In this case, the issue of costs is less pressing.<\/p>\n<p>There are also managed services that charge a fixed fee for the operation of each Kubernetes cluster (for example, <noindex><a rel=\"nofollow\" href=\"https:\/\/aws.amazon.com\/eks\/\">Amazon Elastic Kubernetes Service, EKS<\/a><\/noindex>).<\/p>\n<h3>+ Efficient administration<\/h3>\n<p>\nManaging one cluster is easier than managing several.<\/p>\n<p>Administration can include the following tasks:<\/p>\n<ul>\n<li> upgrading the version of Kubernetes;<\/li>\n<li> configuring the CI\/CD pipeline;<\/li>\n<li> installing the CNI plugin;<\/li>\n<li> setting up user authentication systems;<\/li>\n<li> installing an admission controller;<\/li>\n<\/ul>\n<p>\nand many others\u2026<\/p>\n<p>In the case of a single cluster, you'll only have to do all of this once.<\/p>\n<p>For multiple clusters, you'll need to repeat these operations multiple times, which will likely require some automation tools to ensure consistency and uniformity in the process.<\/p>\n<p><i>Now, a few words about the downsides.<\/i><\/p>\n<h3>\u2212 Single point of failure<\/h3>\n<p>\nIn the event of a failure of the <i>single<\/i> cluster, all <i>all<\/i> workloads will stop working!<\/p>\n<p>There are many scenarios where something can go wrong:<\/p>\n<ul>\n<li> upgrading Kubernetes leads to unexpected side effects;<\/li>\n<li> a cluster-wide component (for example, the CNI plugin) starts malfunctioning;<\/li>\n<li> one of the cluster components is misconfigured;<\/li>\n<li> failure in the underlying infrastructure.<\/li>\n<\/ul>\n<p>\nOne such incident can cause significant damage to all workloads hosted in the shared cluster.<\/p>\n<h3>\u2212 Lack of strict isolation<\/h3>\n<p>\nWorking in a shared cluster means that applications share hardware, network capabilities, and the operating system on the cluster nodes.<\/p>\n<p>In a sense, two containers with two different applications running on the same node are like two processes running on the same machine under the same OS kernel.<\/p>\n<p><i>Linux containers provide some form of isolation, but it is nowhere near as strong as that provided by, say, virtual machines. Essentially, a process in a container is the same as a process running in the host operating system.<\/i><\/p>\n<p>This can become a security concern: such an arrangement theoretically allows unrelated applications to interact with each other (intentionally or accidentally).<\/p>\n<p>Moreover, all workloads in the Kubernetes cluster share some common cluster services, such as <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/dns-pod-service\/\">DNS<\/a><\/noindex> \u2014 this allows applications to find the services of other applications in the cluster.<\/p>\n<p><i>All the above points can have different implications depending on the security requirements of the applications.<\/i><\/p>\n<p>Kubernetes provides various tools to prevent issues in security, such as <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/policy\/pod-security-policy\/\">PodSecurityPolicies<\/a><\/noindex> and <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/network-policies\/\">NetworkPolicies<\/a><\/noindex>. However, proper configuration requires specific experience, and they cannot completely close all security gaps.<\/p>\n<p>It is essential to always remember that Kubernetes was originally designed for <i>collaboration<\/i>, not for <i>isolation and security<\/i>.<\/p>\n<h3>\u2212 No strict multi-tenancy<\/h3>\n<p>\nGiven the abundance of shared resources in the Kubernetes cluster, there are numerous ways in which different applications can \"step on each other's toes.\"<\/p>\n<p>For instance, one application can monopolize a shared resource (like CPU or memory) and deprive other applications running on the same node of access to it.<\/p>\n<p>Kubernetes provides various mechanisms to control such behavior, such as <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/manage-compute-resources-container\/\">resource requests and limits<\/a><\/noindex> <i>(see also the article \"<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/489668\/\"> CPU limits and aggressive throttling in Kubernetes <\/a><\/noindex>\u201d \u2014 ed. note)<\/i>, <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/policy\/resource-quotas\/\">ResourceQuotas<\/a><\/noindex> and <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/policy\/limit-range\/\">LimitRanges<\/a><\/noindex>. However, as with security, their configuration is quite non-trivial, and they cannot prevent all unforeseen side effects.<\/p>\n<h3>\u2212 A large number of users<\/h3>\n<p>\nIn the case of a single cluster, access must be granted to many people. The larger the number of users, the higher the risk that someone might \"break\" something.<\/p>\n<p>Within the cluster, you can control who can do what with the help of <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/reference\/access-authn-authz\/rbac\/\">role-based access control (RBAC)<\/a><\/noindex> <i>(see the article \"<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/470503\/\"> Users and RBAC Authorization in Kubernetes <\/a><\/noindex>\u201d \u2014 ed. note)<\/i>. However, it will not prevent users from \"breaking\" something within their area of responsibility.<\/p>\n<h3>\u2212 Clusters cannot grow indefinitely<\/h3>\n<p>\nA cluster that is used for all workloads will likely be quite large (in terms of the number of nodes and pods).<\/p>\n<p>But here arises another problem: clusters in Kubernetes cannot grow indefinitely.<\/p>\n<p>There is a theoretical limit on the size of a cluster. In Kubernetes, it is about <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/setup\/best-practices\/cluster-large\/\">5000 nodes, 150 thousand pods, and 300 thousand containers<\/a><\/noindex>.<\/p>\n<p>However, in real life, problems can arise much sooner\u2014in fact, at just <noindex><a rel=\"nofollow\" href=\"https:\/\/events19.lfasiallc.com\/wp-content\/uploads\/2017\/11\/BoF_-Not-One-Size-Fits-All-How-to-Size-Kubernetes-Clusters_Guang-Ya-Liu-_-Sahdev-Zala.pdf\">500 nodes<\/a><\/noindex>.<\/p>\n<p>The issue is that large clusters put a high load on the Kubernetes control plane. In other words, maintaining the cluster operational and effectively utilizing resources requires careful configuration.<\/p>\n<p><i>This issue is explored in the corresponding article on the original blog titled \"<noindex><a rel=\"nofollow\" href=\"https:\/\/learnk8s.io\/kubernetes-node-size\">Architecting Kubernetes clusters \u2014 choosing a worker node size<\/a><\/noindex>\u00bb.<\/i><\/p>\n<p><i>But let's consider the opposite approach: many small clusters.<\/i><\/p>\n<h2>2. Many small, specialized clusters<\/h2>\n<p>\nWith this approach, you use a separate cluster for each deployed component:<\/p>\n<p><img decoding=\"async\" alt=\"Designing Kubernetes Clusters: How Many Should There Be?\" src=\"\/wp-content\/uploads\/2020\/05\/2320f62d945944f2e26f07252e9b8440.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Many small clusters<\/i><\/p>\n<p>For the purposes of this article, a <i>deployed component<\/i> is understood to be an instance of an application\u2014for example, a dev version of a specific application.<\/p>\n<p>In this strategy, Kubernetes is used as a specialized <b>runtime<\/b> for individual application instances.<\/p>\n<p><i>Let's look at the pros and cons of this approach.<\/i><\/p>\n<h3>+ Limited \"blast radius\"<\/h3>\n<p>\nIn the event of a 'breakdown' of the cluster, the negative impact is limited only to those workloads that were deployed on that cluster. All other workloads remain unaffected.<\/p>\n<h3>+ Isolation<\/h3>\n<p>\nWorkloads hosted in individual clusters do not share resources like CPU, memory, operating system, network, or other services.<\/p>\n<p>As a result, we achieve strict isolation between unrelated applications, which can positively impact their security.<\/p>\n<h3>+ Few users<\/h3>\n<p>\nConsidering that each cluster contains only a limited set of workloads, the number of users with access to it is reduced.<\/p>\n<p>The fewer people who have access to the cluster, the lower the risk of something \"breaking.\"<\/p>\n<p><i>Let's look at the downsides.<\/i><\/p>\n<h3>\u2212 Inefficient resource utilization<\/h3>\n<p>\nAs mentioned earlier, each Kubernetes cluster requires a certain set of control resources: master nodes, control plane components, monitoring and logging solutions.<\/p>\n<p>In the case of a large number of small clusters, more resources must be allocated for management.<\/p>\n<h3>\u2212 Costliness<\/h3>\n<p>\nInefficient resource utilization inherently leads to high expenses.<\/p>\n<p>For example, having 30 master nodes instead of three with the same computing power will inevitably affect costs.<\/p>\n<h3>\u2212 Administration complexities<\/h3>\n<p>\nManaging multiple Kubernetes clusters is much more difficult than working with a single one.<\/p>\n<p>For instance, you will need to configure authentication and authorization for each cluster. Updating the Kubernetes version will also need to be done several times.<\/p>\n<p>You will likely need to apply automation to improve the efficiency of all these tasks.<\/p>\n<p><i>Now let's consider less extreme scenarios.<\/i><\/p>\n<h2>3. One cluster for each application<\/h2>\n<p>\nIn this approach, you create a separate cluster for all instances of a specific application:<\/p>\n<p><img decoding=\"async\" alt=\"Designing Kubernetes Clusters: How Many Should There Be?\" src=\"\/wp-content\/uploads\/2020\/05\/238ee74d4e4dc42b7daeadc1ce484905.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Cluster per application<\/i><\/p>\n<p>This method can be seen as a generalization of the principle of '<b>one cluster per team<\/b>,' since a team of engineers typically works on one or more applications.<\/p>\n<p><i>Let's look at the pros and cons of this approach.<\/i><\/p>\n<h3>+ The cluster can be tailored for the application<\/h3>\n<p>\nIf the application has specific requirements, they can be implemented in the cluster without affecting other clusters.<\/p>\n<p>Such needs may include workers with GPU, specific CNI plugins, service mesh, or some other service.<\/p>\n<p>Each cluster can be configured to suit the application it runs, containing only what is necessary.<\/p>\n<h3>\u2212 Different environments in one cluster<\/h3>\n<p>\nThe downside of this approach is that instances of applications from different environments coexist in the same cluster.<\/p>\n<p>For example, the production version of the application runs in the same cluster as the development version. This also means that developers operate in the same cluster where the production version of the application is being deployed.<\/p>\n<p>If a failure occurs in the cluster due to the actions of developers or bugs in the development version, the production version may also suffer \u2014 a significant drawback of this approach.<\/p>\n<p><i>And finally, the last scenario on our list.<\/i><\/p>\n<h2>4. One cluster for each environment<\/h2>\n<p>\nThis scenario involves dedicating a separate cluster for each environment:<\/p>\n<p><img decoding=\"async\" alt=\"Designing Kubernetes Clusters: How Many Should There Be?\" src=\"\/wp-content\/uploads\/2020\/05\/157da599edf178832b1b15459786fbc8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>One cluster per environment<\/i><\/p>\n<p>For instance, you may have clusters <i>dev<\/i>, <i>test<\/i> and <i>prod<\/i>, in which you will run all instances of the application intended for a specific environment.<\/p>\n<p><i>Here are the pros and cons of this approach.<\/i><\/p>\n<h3>+ Isolation of the production environment<\/h3>\n<p>\nUnder this approach, all environments are isolated from each other. However, in practice, this is especially important for the production environment.<\/p>\n<p>Production versions of the application are now independent of what is happening in other clusters and environments.<\/p>\n<p>Thus, if a problem suddenly arises in the dev cluster, the production versions of the applications will continue to work as if nothing happened.<\/p>\n<h3>+ The cluster can be tailored to the environment<\/h3>\n<p>\nEach cluster can be adjusted to its environment. For example, you can:<\/p>\n<ul>\n<li> install development and debugging tools in the dev cluster;<\/li>\n<li> install testing frameworks and tools in the cluster; <i>test<\/i>;<\/li>\n<li> use more powerful hardware and network channels in the cluster; <i>prod<\/i>.<\/li>\n<\/ul>\n<p>\nThis allows for increased efficiency in both the development and operation of applications.<\/p>\n<h3>+ Restricting access to the production cluster<\/h3>\n<p>\nThe need to work directly with the prod cluster arises infrequently, so the circle of people with access can be significantly limited.<\/p>\n<p>One can go even further and completely deny people access to this cluster, and perform all deployments using an automated CI\/CD tool. This approach will minimize the risk of human errors precisely where it is most critical.<\/p>\n<p><i>Now, a few words about the downsides.<\/i><\/p>\n<h3>\u2212 Lack of isolation between applications<\/h3>\n<p>\nThe main drawback of the approach is the absence of hardware and resource isolation between applications.<\/p>\n<p>Unrelated applications share the cluster\u2019s resources: the system kernel, CPU, memory, and some other services.<\/p>\n<p>As mentioned earlier, this can be potentially dangerous.<\/p>\n<h3>\u2212 Inability to localize application dependencies<\/h3>\n<p>\nIf an application has special requirements, they must be met in all clusters.<\/p>\n<p>For example, if an application requires a GPU, then each cluster must contain at least one worker with a GPU (even if it is only used by that application).<\/p>\n<p>As a result, we risk incurring higher costs and inefficient use of resources.<\/p>\n<h2>Conclusion<\/h2>\n<p>\nWith a certain set of applications, they can be placed in several large clusters or many small ones.<\/p>\n<p>The article discusses the pros and cons of various approaches, from a single global cluster to several small and specialized ones.<\/p>\n<ul>\n<li> one large shared cluster;<\/li>\n<li> multiple small specialized clusters;<\/li>\n<li> one cluster for each application;<\/li>\n<li> one cluster for each environment.<\/li>\n<\/ul>\n<p>\n<i>So, which approach should be chosen?<\/i><\/p>\n<p>As usual, the answer depends on the use case: you need to weigh the pros and cons of different approaches and choose the most optimal option.<\/p>\n<p>However, the choice is not limited to the examples above \u2014 you can use any combination of them!<\/p>\n<p>For example, you can set up a couple of clusters for each team: a cluster for development (where the environments <i>dev<\/i> and <i>test<\/i>) and a cluster for <i>production<\/i> (where the production environment will be).<\/p>\n<p>Based on the information in this article, you will be able to appropriately optimize the pros and cons for the specific scenario. Good luck!<\/p>\n<h2>P.S.<\/h2>\n<p>\nAlso read in our blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/484954\/\">A visual guide to troubleshooting Kubernetes issues<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/480946\/\">Logs in Kubernetes (and beyond) today: expectations vs. reality<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/478306\/\">Service Mesh: what every Software Engineer needs to know about the most hyped technology<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468679\/\">The Genie<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Source: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/498100\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u044d\u0442\u043e\u0442 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b \u043e\u0442 \u043e\u0431\u0440\u0430\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u0430 learnk8s \u2014 \u043e\u0442\u0432\u0435\u0442 \u043d\u0430 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0439 \u0432\u043e\u043f\u0440\u043e\u0441 \u043f\u0440\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0438 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u043d\u0430 \u0431\u0430\u0437\u0435 Kubernetes. \u041d\u0430\u0434\u0435\u0435\u043c\u0441\u044f, \u0447\u0442\u043e \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0440\u0430\u0437\u0432\u0451\u0440\u043d\u0443\u0442\u044b\u0435 \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u044f \u043f\u043b\u044e\u0441\u043e\u0432 \u0438 \u043c\u0438\u043d\u0443\u0441\u043e\u0432 \u043a\u0430\u0436\u0434\u043e\u0433\u043e \u0438\u0437 \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u043e\u0432 \u043f\u043e\u043c\u043e\u0433\u0443\u0442 \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u043e\u043f\u0442\u0438\u043c\u0430\u043b\u044c\u043d\u044b\u0439 \u0432\u044b\u0431\u043e\u0440 \u0438 \u0434\u043b\u044f \u0432\u0430\u0448\u0435\u0433\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u0430. TL;DR: \u043e\u0434\u0438\u043d \u0438 \u0442\u043e\u0442 \u0436\u0435 \u043d\u0430\u0431\u043e\u0440 \u0440\u0430\u0431\u043e\u0447\u0438\u0445 \u043d\u0430\u0433\u0440\u0443\u0437\u043e\u043a \u043c\u043e\u0436\u043d\u043e \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u043a\u0440\u0443\u043f\u043d\u044b\u0445 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 (\u043d\u0430 \u043a\u0430\u0436\u0434\u044b\u0439 \u043a\u043b\u0430\u0441\u0442\u0435\u0440 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":80077,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-80076","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 Kubernetes-\u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u0432: \u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0438\u0445 \u0434\u043e\u043b\u0436\u043d\u043e \u0431\u044b\u0442\u044c? | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-02T23:42:34+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-02T23:42:34+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Designing Kubernetes Clusters: How Many Should There Be? | ProHoster","description":"Example.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 Kubernetes-\u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u0432: \u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0438\u0445 \u0434\u043e\u043b\u0436\u043d\u043e \u0431\u044b\u0442\u044c? | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/proektirovanie-kubernetes-klasterov-skolko-ih-dolzhno-byt","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-02T23:42:34+00:00","article:modified_time":"2020-05-02T23:42:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"80076","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 16:24:58","updated":"2022-10-02 20:23:35","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/80076","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=80076"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/80076\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/80077"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=80076"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=80076"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=80076"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}