{"id":82223,"date":"2020-05-20T13:42:34","date_gmt":"2020-05-20T11:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-organizacziya-kubernetes-s-prostranstvom-imen"},"modified":"2020-05-20T13:42:34","modified_gmt":"2020-05-20T11:42:34","slug":"luchshie-praktiki-kubernetes-organizacziya-kubernetes-s-prostranstvom-imen","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-organizacziya-kubernetes-s-prostranstvom-imen","title":{"rendered":"Best Practices for Kubernetes. Organizing Kubernetes with Namespaces","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Best Practices for Kubernetes. Creating Small Containers<\/a><\/noindex><\/p>\n

As you start creating more and more Kubernetes services, tasks that initially seem simple can become complicated. For instance, developer teams cannot create services or deployments with the same name. If you have thousands of pods, simply listing them will take a lot of time, not to mention ensuring proper management. And that's just the tip of the iceberg.<\/p>\n

Let's look at how namespaces help simplify resource management in Kubernetes. So, what exactly is a namespace? A namespace can be thought of as a virtual cluster within your Kubernetes cluster. You can have multiple isolated namespaces within a single Kubernetes cluster. They can truly assist you and your teams with organization, security, and even system performance.<\/p>\n

\"Best
\n
\nIn most Kubernetes distributions, the cluster comes out of the box with a namespace called \"default.\" In reality, there are three namespaces that Kubernetes deals with: default, kube-system, and kube-public. Currently, kube-public is not used very frequently.<\/a><\/noindex><\/p>\n

\"Best
\n
\nIt\u2019s a good idea to leave the kube namespace alone, especially in a managed system like Google Kubernetes Engine. It uses the \"default\" namespace as a place where your services and applications are created. There's nothing particularly special about it, except that Kubernetes is configured to use it out of the box, and you cannot delete it. It works well for getting started and systems with low performance, but I would not recommend using the default namespace in larger production systems. In such cases, one team of developers could easily overwrite another's code and disrupt another team\u2019s work without even realizing it.<\/p>\n

Therefore, you should create several namespaces and use them to segment your services into manageable units. A namespace can be created with a single command. If you want to create a namespace named test, use the command $ kubectl create namespace test, or simply create a YAML file and use it like any other Kubernetes resource.<\/p>\n

\"Best
\n
\nYou can view all namespaces using the command $ kubectl get namespace. <\/p>\n

\"Best
\n
\nAfter executing it, you will see three built-in namespaces and a new namespace called 'test'. Let's look at a simple YAML file intended to create a pod. You may notice that there is no mention of the namespace.<\/p>\n

\"Best
\n
\nIf you use kubectl to apply this file, it will create a mypod module in the currently active namespace. This will be the default namespace until you change it. There are two ways to tell Kubernetes which namespace you want to create your resource in. The first way is to use the namespace flag when creating the resource. <\/p>\n

\"Best
\n
\nThe second way is to specify the namespace in the YAML declaration.<\/p>\n

\"Best
\n
\nIf you specify the namespace in the YAML, the resource will always be created in that namespace. If you try to use a different namespace while using the namespace flag, the command will fail. Now, if you try to find your pod, you won't be able to. <\/p>\n

\"Best
\n
\nThis happens because all commands are executed outside the currently active namespace. To locate your pod, you need to use the namespace flag, but this quickly becomes tedious, especially if you're a developer in a team that uses its own namespace and doesn't want to use that flag for every single command. Let's look at how this can be addressed.<\/p>\n

\"Best
\n
\nOut of the box, your active namespace is called default. If you do not specify the namespace in the resource YAML, all Kubernetes commands will use this active default namespace. Unfortunately, managing the active namespace with kubectl can often be challenging. However, there is a very useful tool called Kubens that simplifies this process significantly. When you run the kubens command, you will see all namespaces with the currently active namespace highlighted. <\/p>\n

\"Best
\n
\nTo switch the active namespace to the test namespace, you simply run the command $ kubens test. If you then run the command $ kubens again, you will see that the new active namespace \u2013 test \u2013 is now highlighted.<\/p>\n

\"Best
\n
\nThis means you don't need a namespace flag to see a pod in the test namespace.<\/p>\n

\"Best
\n
\nThus, namespaces are hidden from each other but not isolated from one another. A service in one namespace can easily communicate with a service in another namespace, which is often very useful. The ability to communicate between different namespaces means that your developers' service can interact with another dev team's service in a different namespace.<\/p>\n

Typically, when your application wants to access a Kubernetes service, you use the built-in DNS service discovery and simply specify the service name to your application. However, you can create a service with the same name in multiple namespaces, which is not allowed. <\/p>\n

\"Best
\n
\nFortunately, this can be easily worked around by using the fully qualified DNS address. Services in Kubernetes expose their endpoints using a common DNS pattern. It looks something like this:<\/p>\n

\"Best
\n
\nGenerally, you just need the service name, and DNS will automatically resolve the full address. <\/p>\n

\"Best
\n
\nHowever, if you need to access a service in another namespace, just use the service name plus the namespace name:<\/p>\n

\"Best
\n
\nFor example, if you want to connect to a database service in the test namespace, you can use the address database.test.<\/p>\n

\"Best
\n
\nIf you want to connect to a database service in the prod namespace, you use database.prod.<\/p>\n

\"Best
\n
\nIf you truly want to isolate and restrict access to a namespace, Kubernetes allows you to do this using Kubernetes Network Policies. I'll discuss this in the next series. <\/p>\n

I often get asked how many namespaces should be created and for what purposes? What exactly is a managed data fragment?<\/p>\n

If you create too many namespaces, they will simply get in your way. If there are too few, you'll lose all the advantages of such a solution. I think there are four main stages that every company goes through in the process of establishing its organizational structure. Depending on the stage of development your project or company is at, you can adopt the appropriate strategy for creating namespaces.<\/p>\n

Imagine that you are part of a small team working on developing 5-10 microservices, and you can easily gather all the developers in one room. In this situation, it makes sense to run all production services in the default namespace. Of course, for greater flexibility, you could use two namespaces \u2014 one for production and one for development. And most likely, you are testing your development on your local machine using something like Minikube. <\/p>\n

Suppose the conditions have changed, and now you have a rapidly growing team that is working on more than 10 microservices at the same time. There comes a point when you need to use multiple clusters or namespaces, separately for production and development. You can break the team into several subgroups so that each has its own microservices, and each of these teams could choose its own namespace to facilitate the management of development and software releases.<\/p>\n

\"Best
\n
\nAs each team member gains insight into how the system works as a whole, coordinating each change with all the other developers becomes increasingly difficult. Trying to spin up the full stack on your local machine becomes more challenging day by day. <\/p>\n

In large companies, developers often do not know who is working on what specifically. Teams communicate through service contracts or use Service Mesh technology, which adds an abstraction layer over the network, similar to the configuration tool Istio. Attempting to run the entire stack locally is practically impossible. I strongly recommend using a continuous delivery (CD) platform like Spinnaker in Kubernetes. Thus, the moment comes when each team certainly needs its own namespace. Each team may also choose several namespaces for the dev and prod environments. <\/p>\n

Finally, there are large entrepreneurial companies where one group of developers doesn't even know about the existence of other groups. Such a company might hire external developers who interact through well-documented APIs. Each such group contains several teams and multiple microservices. In this case, it is necessary to utilize all the tools I mentioned earlier.<\/p>\n

\"Best
\n
\nProgrammers should not deploy services manually and should not have access to namespaces that do not concern them. At this stage, it makes sense to have several clusters to reduce the 'blast radius' of poorly configured applications, to simplify billing processes and resource management.<\/p>\n

Thus, the proper use of namespaces by your organization allows Kubernetes to be more manageable, controlled, secure, and flexible.<\/p>\n

Best Practices for Kubernetes. Checking Kubernetes Health with Readiness and Liveness Tests<\/a><\/noindex><\/p>\n

\r\n \"Play\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

A little advertisement \ud83d\ude42<\/h3>\n

\nThank you for staying with us. Do you enjoy our articles? Want to see more interesting content? Support us by placing an order or recommending us to your friends, cloud VPS for developers starting at $4.99<\/a><\/noindex>, a unique entry-level server alternative that we have created for you:<\/b> The whole truth about VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps from $19 or how to properly share a server?<\/a><\/noindex> (options available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).<\/p>\n

Dell R730xd at half the price in the Equinix Tier IV data center in Amsterdam?<\/b> Only with us 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100TB starting at $199<\/a><\/noindex> in the Netherlands! Dell R420 \u2014 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 from $99!<\/b><\/b> Read about how To build a corporate-class infrastructure using Dell R730xd E5-2650 v4 servers costing 9000 euros for peanuts?<\/a><\/noindex>
\n
Source: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041b\u0443\u0447\u0448\u0438\u0435 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 Kubernetes. \u0421\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u041f\u043e \u043c\u0435\u0440\u0435 \u0442\u043e\u0433\u043e \u043a\u0430\u043a \u0432\u044b \u043d\u0430\u0447\u0438\u043d\u0430\u0435\u0442\u0435 \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u0442\u044c \u0432\u0441\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 \u0438 \u0431\u043e\u043b\u044c\u0448\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 Kubernetes, \u043f\u0440\u043e\u0441\u0442\u044b\u0435 \u043f\u043e \u043d\u0430\u0447\u0430\u043b\u0443 \u0437\u0430\u0434\u0430\u0447\u0438 \u043d\u0430\u0447\u0438\u043d\u0430\u044e\u0442 \u0443\u0441\u043b\u043e\u0436\u043d\u044f\u0442\u044c\u0441\u044f. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432 \u043d\u0435 \u043c\u043e\u0433\u0443\u0442 \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u0442\u044c \u0441\u043b\u0443\u0436\u0431\u044b \u0438\u043b\u0438 \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u043f\u043e\u0434 \u043e\u0434\u043d\u0438\u043c \u0438 \u0442\u0435\u043c \u0436\u0435 \u0438\u043c\u0435\u043d\u0435\u043c. \u0415\u0441\u043b\u0438 \u0443 \u0432\u0430\u0441 \u0442\u044b\u0441\u044f\u0447\u0438 \u043f\u043e\u0434\u043e\u0432, \u0438\u0445 \u043f\u0440\u043e\u0441\u0442\u043e\u0435 \u043f\u0435\u0440\u0435\u0447\u0438\u0441\u043b\u0435\u043d\u0438\u0435 \u0437\u0430\u0439\u043c\u0435\u0442 \u043a\u0443\u0447\u0443 \u0432\u0440\u0435\u043c\u0435\u043d\u0438, \u043d\u0435 \u0433\u043e\u0432\u043e\u0440\u044f \u043e \u0442\u043e\u043c, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":82224,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-82223","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Kubernetes Best Practices. Organizing Kubernetes with Namespaces | ProHoster","description":"Best practices for Kubernetes.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-organizacziya-kubernetes-s-prostranstvom-imen","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\u041b\u0443\u0447\u0448\u0438\u0435 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 Kubernetes. \u041e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f Kubernetes \u0441 \u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0441\u0442\u0432\u043e\u043c \u0438\u043c\u0435\u043d | ProHoster","og:description":"\u041b\u0443\u0447\u0448\u0438\u0435 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 Kubernetes.","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-organizacziya-kubernetes-s-prostranstvom-imen","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-20T11:42:34+00:00","article:modified_time":"2020-05-20T11:42:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"82223","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 15:41:29","updated":"2022-09-29 19:27:31","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\/82223","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=82223"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/82223\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/82224"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=82223"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=82223"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=82223"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}