{"id":34735,"date":"2019-10-31T22:00:06","date_gmt":"2019-10-31T19:00:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/znakomstvo-s-helm-3\/"},"modified":"2019-10-31T22:00:06","modified_gmt":"2019-10-31T19:00:06","slug":"znakomstvo-s-helm-3","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/znakomstvo-s-helm-3","title":{"rendered":"Introducing Helm 3","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Introducing Helm 3\" src=\"\/wp-content\/uploads\/2019\/05\/6de0e2887ddcc802f1dd71c902325401.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Note: translation.<\/b>: May 16 of this year marks a significant milestone in the development of the package manager for Kubernetes \u2014 Helm. On this day, the first alpha release of the upcoming major version of the project \u2014 3.0 \u2014 was announced. Its release will bring substantial and long-awaited changes to Helm, which many in the Kubernetes community have high hopes for. We are among them, as we actively use Helm for application deployment: we have integrated it into our CI\/CD implementation tool. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">werf<\/a><\/noindex> and from time to time, we contribute to the development of upstream. This translation combines 7 notes from the official Helm blog, timed to the first alpha release of Helm 3, discussing the project's history and the key features of Helm 3. The author is Matt \"bacongobbler\" Fisher, a Microsoft employee and one of the key maintainers of Helm.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>On October 15, 2015, the project known today as Helm was born. Just a year after its founding, the Helm community joined Kubernetes, actively working on Helm 2 along the way. In June 2018, Helm <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cncf.io\/blog\/2018\/06\/01\/cncf-to-host-helm\/\">became a part of the CNCF<\/a><\/noindex> as an incubating project. Fast forward to the present \u2014 and the first alpha release of the new Helm 3 is already on the way <i>(this release <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">has already taken place<\/a><\/noindex> in mid-May \u2014 ed.)<\/i>.<\/p>\n<p>In this material, I will talk about how it all began, how we reached the current stage, present some unique features available in the first alpha release of Helm 3, and explain how we plan to evolve further.<\/p>\n<p>Summary:<\/p>\n<ul>\n<li>the history of Helm's creation;<\/li>\n<li>A gentle farewell to Tiller<\/li>\n<li>chart repositories;<\/li>\n<li>release management;<\/li>\n<li>changes in chart dependencies;<\/li>\n<li>library charts;<\/li>\n<li>what's next?<\/li>\n<\/ul>\n<p><\/p>\n<h2>The History of Helm's Creation<\/h2>\n<p><\/p>\n<h3>Birth<\/h3>\n<p>\nHelm 1 started as an Open Source project created by Deis. We were a small startup, <noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.microsoft.com\/blog\/2017\/04\/10\/microsoft-acquire-deis-help-companies-innovate-containers\/\">acquired<\/a><\/noindex> by Microsoft in the spring of 2017. Our other Open Source project, also named Deis, had a tool <code>deisctl<\/code>, which was used (among other things) for installing and operating the Deis platform in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/coreos\/fleet\">a Fleet cluster.<\/a><\/noindex>At that time, Fleet was one of the first platforms for orchestrating containers.<\/p>\n<p>In mid-2015, we decided to change course and migrated Deis (then renamed to Deis Workflow) from Fleet to Kubernetes. One of the first tools to be redesigned was the installation tool. <code>deisctl<\/code>We used it for installing and managing Deis Workflow in the Fleet cluster.<\/p>\n<p>Helm 1 was designed in the image of well-known package managers, such as Homebrew, apt, and yum. Its primary task was to simplify tasks such as packaging and installing applications in Kubernetes. Helm was officially introduced in 2015 at the KubeCon conference in San Francisco.<\/p>\n<p>Our first attempt with Helm worked, but it came with serious limitations. It took a set of Kubernetes manifests, enhanced with generators as input YAML blocks, <i>(front-matter)<\/i>*, and loaded the results into Kubernetes.<\/p>\n<p><i>* <b>Note: translation.<\/b>: From the first version of Helm, YAML syntax was chosen to describe Kubernetes resources, and Jinja templates and Python scripts were supported for writing configurations. We wrote more about this and the structure of the first version of Helm in the chapter 'A Brief History of Helm' of this material. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417079\/\">this material<\/a><\/noindex>.<\/i><\/p>\n<p>For example, to replace a field in a YAML file, you needed to add the following construct to the manifest:<\/p>\n<pre><code class=\"plaintext\">#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my\/pod.yaml<\/code><\/pre>\n<p>\nIt's great that today we have templating engines, isn't it?<\/p>\n<p>For many reasons, this early Kubernetes installer required a hardcoded list of manifest files and only executed a small fixed sequence of events. It was so difficult to use that the Deis Workflow R&amp;D team had a tough time trying to port their product to this platform\u2014however, the seeds of the idea had already been sown. Our first attempt became a great learning opportunity: we realized that we were truly passionate about creating pragmatic tools that solve everyday problems for our users.<\/p>\n<p>Building on the experience of past mistakes, we set out to develop Helm 2.<\/p>\n<h3>Creating Helm 2<\/h3>\n<p>\nAt the end of 2015, the Google team reached out to us. They were working on a similar tool for Kubernetes. The Deployment Manager for Kubernetes was a port of an existing tool that was used for Google Cloud Platform. 'Would we like to spend a few days discussing the similarities and differences?' they asked.<\/p>\n<p>In January 2016, the teams from Helm and Deployment Manager met in Seattle to exchange ideas. The discussions concluded with an ambitious plan: to merge both projects to create Helm 2. Together with Deis and Google, the team welcomed new contributors. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/skippbox\">SkippBox<\/a><\/noindex> <i>(now part of Bitnami \u2014 translator's note)<\/i>, joined the development team, and we started working on Helm 2.<\/p>\n<p>We wanted to maintain the simplicity of using Helm, but add the following:<\/p>\n<ul>\n<li> chart templates for customization;<\/li>\n<li> in-cluster management for teams;<\/li>\n<li> a first-class chart repository;<\/li>\n<li> a stable package format with signing capability;<\/li>\n<li> a strong commitment to semantic versioning and maintaining backward compatibility between versions.<\/li>\n<\/ul>\n<p>\nTo achieve these goals, a second component was added to the Helm ecosystem. This in-cluster component was called Tiller and was responsible for installing and managing Helm charts.<\/p>\n<p>Since the release of Helm 2 in 2016, Kubernetes has undergone several significant innovations. Role-based access control (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/422801\/\">RBAC<\/a><\/noindex>) has ultimately replaced attribute-based access control (ABAC). New resource types were introduced (Deployments were still in beta at that time). Custom Resource Definitions were invented (originally named Third Party Resources or TPRs). Most importantly, a set of best practices emerged.<\/p>\n<p>Against the backdrop of all these changes, Helm continued to serve the Kubernetes community faithfully. After three years and numerous additions, it became clear that substantial changes were needed in the codebase for Helm to continue meeting the growing needs of the evolving ecosystem.<\/p>\n<h2>A gentle farewell to Tiller<\/h2>\n<p>\nDuring the development of Helm 2, we introduced Tiller as part of our integration with Google's Deployment Manager. Tiller played a crucial role for teams working within a shared cluster: it allowed various specialists managing the infrastructure to interact with the same set of releases.<\/p>\n<p>As role-based access control (RBAC) became enabled by default in Kubernetes 1.6, working with Tiller in production became more complex. Due to the vast number of potential security policies, our position was to offer a permissive configuration by default. This allowed newcomers to experiment with Helm and Kubernetes without needing to delve into security settings first. Unfortunately, this permissive configuration could grant the user an excessively broad range of permissions that were unnecessary. DevOps and SRE engineers had to learn additional operational steps when installing Tiller in a multi-tenant cluster.<\/p>\n<p>By learning how community members used Helm in specific situations, we realized that the release management system of Tiller didn\u2019t need to rely on an in-cluster component to maintain states or function as a central hub of release information. Instead, we could simply fetch data from the Kubernetes API server, generate the chart on the client side, and save the installation record in Kubernetes.<\/p>\n<p>The primary task of Tiller could be accomplished without Tiller, so one of our first decisions regarding Helm 3 was to completely eliminate Tiller.<\/p>\n<p>With Tiller's departure, Helm's security model has been radically simplified. Helm 3 now supports all modern security, identity, and authorization mechanisms of current Kubernetes. Helm permissions are defined using <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/organize-cluster-access-kubeconfig\/\">the kubeconfig file.<\/a><\/noindex>Cluster administrators can limit user rights with any level of granularity. Releases are still stored within the cluster, and the rest of Helm's functionality remains intact.<\/p>\n<h2>Chart Repositories<\/h2>\n<p>\nAt a high level, a chart repository is a location where charts can be stored and shared. The Helm client packages and uploads charts to the repository. Simply put, a chart repository is a primitive HTTP server with an index.yaml file and some packaged charts.<\/p>\n<p>While there are some advantages to having the chart repository API meet basic storage requirements, it also has several disadvantages:<\/p>\n<ul>\n<li> Chart repositories are poorly compatible with most security implementations required in a production environment. Having a standard API for authentication and authorization is crucial in production scenarios.<\/li>\n<li> Helm\u2019s tools for tracking chart provenance, used for signing, integrity verification, and provenance of charts, are an optional part of the chart publishing process.<\/li>\n<li> In multi-user scenarios, the same chart can be uploaded by another user, effectively doubling the storage space required for the same content. Smarter repositories have been developed to address this issue, but they are not part of the formal specification.<\/li>\n<li> Using a single index file for searching, storing metadata, and retrieving charts has complicated the development of secure multi-user implementations.<\/li>\n<\/ul>\n<p>\nProject <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/docker\/distribution\">Docker Distribution<\/a><\/noindex> (also known as Docker Registry v2) is the successor to Docker Registry and effectively serves as a toolkit for packaging, shipping, storing, and delivering Docker images. Many leading cloud services offer products based on Distribution. Due to this increased attention, the Distribution project has benefited from years of improvements, best practices in security, and real-world testing, making it one of the most successful unsung heroes in the Open Source world.<\/p>\n<p>But did you know that the Distribution project was designed to distribute any form of content, not just container images?<\/p>\n<p>Thanks to the efforts of <noindex><a rel=\"nofollow\" href=\"https:\/\/www.opencontainers.org\/\">Open Container Initiative<\/a><\/noindex> (or OCI), Helm charts can be hosted on any instance of Distribution. While this process is still experimental, work on supporting logins and other features necessary for full Helm 3 functionality is not yet complete, but we are very excited about the opportunity to learn from the discoveries made by the OCI and Distribution teams over the years. And with their mentorship and guidance, we are learning what it means to operate a highly available service at scale.<\/p>\n<p>A more detailed description of some upcoming changes in Helm chart repositories is available <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.bacongobbler.com\/post\/2019-01-25-distributing-with-distribution\/\">at the link<\/a><\/noindex>.<\/p>\n<h2>Release Management<\/h2>\n<p>\nIn Helm 3, the application state is tracked within the cluster by a pair of objects:<\/p>\n<ul>\n<li> release object \u2014 represents an instance of an application;<\/li>\n<li> release version secret \u2014 represents the desired state of the application at a specific point in time (e.g., the release of a new version).<\/li>\n<\/ul>\n<p>\nCall <code>helm install<\/code> creates release object and release version secret. The call <code>helm upgrade<\/code> requires the presence of release object (which it can change) and creates a new release version secret containing new values and a prepared manifest.<\/p>\n<p>The Release object contains information about the release, where the release is a specific installation of a named chart and its values. This object describes the top-level metadata about the release. The Release object is maintained throughout the application's lifecycle and acts as the owner of all release version secrets, as well as all objects that are directly created by the Helm chart.<\/p>\n<p>Release version secret links the release to a series of revisions (installation, updates, rollbacks, deletions).<\/p>\n<p>In Helm 2, revisions were exclusively sequential. The call <code>helm install<\/code> created v1, the subsequent update (upgrade) is v2, and so forth. The Release and release version secret were consolidated into a single object known as a revision. Revisions were stored in the same namespace as Tiller, meaning that each release was 'global' in terms of the namespace; as a result, only one instance of a name could be used.<\/p>\n<p>In Helm 3, each release is associated with one or more release version secrets. The Release object always describes the current release deployed in Kubernetes. Each release version secret describes only one version of that release. An update (upgrade), for example, will create a new release version secret and then change the Release object to point to this new version. In the case of a rollback, previous release version secrets can be used to revert the release to its previous state.<\/p>\n<p>After the removal of Tiller, Helm 3 stores release data in the same namespace as the release. This change allows installing a chart with the same release name in another namespace, and the data is retained between updates\/reboots of the cluster in etcd. For example, one can install WordPress in the 'foo' namespace, and then in the 'bar' namespace, and both releases can be named 'wordpress'.<\/p>\n<h2>Changes in chart dependencies<\/h2>\n<p>\nCharts packaged (with <code>helm package<\/code>) for use with Helm 2, can be installed with Helm 3; however, the chart development workflow has been completely reworked, so some adjustments are necessary to continue developing charts with Helm 3. Specifically, the chart dependency management system has changed.<\/p>\n<p>The chart dependency management has shifted from <code>requirements.yaml<\/code> and <code>requirements.lock<\/code> to <code>Chart.yaml<\/code> and <code>Chart.lock<\/code>. This means that charts that used the command <code>helm dependency<\/code>, require some configuration to work in Helm 3.<\/p>\n<p>Let's consider an example. We'll add a dependency to a chart in Helm 2 and see what changes when transitioning to Helm 3.<\/p>\n<p>In Helm 2 <code>requirements.yaml<\/code> it looked like this:<\/p>\n<pre><code class=\"plaintext\">dependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https:\/\/kubernetes-charts.storage.googleapis.com\/\n  condition: mariadb.enabled\n  tags:\n    - database<\/code><\/pre>\n<p>\nIn Helm 3, the same dependency will be reflected in your <code>Chart.yaml<\/code>:<\/p>\n<pre><code class=\"plaintext\">dependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https:\/\/kubernetes-charts.storage.googleapis.com\/\n  condition: mariadb.enabled\n  tags:\n    - database<\/code><\/pre>\n<p>\nCharts are still downloaded and placed in the directory <code>charts\/<\/code>, so subcharts <i>(subcharts)<\/i>, located in the directory <code>charts\/<\/code>, will continue to function unchanged.<\/p>\n<h2>Introducing Library Charts<\/h2>\n<p>\nHelm 3 supports a class of charts known as library charts <i>(library chart)<\/i>. This chart is used by other charts but does not create any release artifacts independently. Library chart templates can only declare elements <code>define<\/code>. Other content is simply ignored. This allows users to reuse and share code snippets that can be leveraged across multiple charts, thereby avoiding duplication and adhering to the principle of <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Don%27t_repeat_yourself\">DRY<\/a><\/noindex>.<\/p>\n<p>Library charts are declared in the section <code>dependencies<\/code> in the file <code>Chart.yaml<\/code>. Installation and management are no different from other charts.<\/p>\n<pre><code class=\"plaintext\">dependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io<\/code><\/pre>\n<p>\nWe are eagerly anticipating the use cases that this component will open up for chart developers, as well as the best practices that may arise from library charts.<\/p>\n<h2>What's next?<\/h2>\n<p>\nHelm 3.0.0-alpha.1 is the foundation upon which we begin building the new version of Helm. In this article, I've outlined some interesting features of Helm 3. Many of these are still in early stages of development, which is perfectly normal; the purpose of an alpha release is to test the idea, gather feedback from early users, and validate our assumptions.<\/p>\n<p>Once the alpha version is released <i>(let's remember that this <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">has already happened<\/a><\/noindex> - translator's note)<\/i>, we will start accepting patches for Helm 3 from the community. It is essential to build a solid foundation that allows for the development and acceptance of new features, while users can feel engaged in the process by opening tickets and submitting fixes.<\/p>\n<p>In this article, I aimed to highlight some significant improvements coming to Helm 3; however, this list is by no means exhaustive. The comprehensive plan for Helm 3 includes innovations such as enhanced upgrade strategies, deeper integration with OCI registries, and the use of JSON schemas for validating chart values. We also plan to clean up the codebase and update the parts that have been neglected over the past three years.<\/p>\n<p>If you feel we\u2019ve missed something, we would love to hear your thoughts!<\/p>\n<p>Join the discussion in our <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.slack.com\/\">Slack channels<\/a><\/noindex>:<\/p>\n<ul>\n<li> <code>#helm-users<\/code> for questions and casual chat with the community;<\/li>\n<li> <code>#helm-dev<\/code> for discussing pull requests, code, and bugs.<\/li>\n<\/ul>\n<p>\nYou can also engage in our weekly Public Developer Calls on Thursdays at 7:30 PM MSK. The meetings focus on discussing tasks that key developers and the community are working on, as well as topics for the week. Anyone is welcome to join and participate in the meeting. The link is available in the Slack channel <code>#helm-dev<\/code>.<\/p>\n<h2>P.S. from the translator<\/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\/417079\/\">The package manager for Kubernetes \u2014 Helm: past, present, future<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438814\/\">A sober look at Helm 2: 'Here it is...'<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/420437\/\">A practical introduction to the package manager for Kubernetes \u2014 Helm<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/441964\/\">Kubernetes tips &amp; tricks: shifting working resources in the cluster under Helm 2 management<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/336170\/\">Practice with dapp. Part 2. Deploying Docker images in Kubernetes using Helm<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Source: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/453734\/\">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.: 16 \u043c\u0430\u044f \u044d\u0442\u043e\u0433\u043e \u0433\u043e\u0434\u0430 \u2014 \u0437\u043d\u0430\u0447\u0438\u043c\u0430\u044f \u0432\u0435\u0445\u0430 \u0432 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0438 \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u0430 \u043f\u0430\u043a\u0435\u0442\u043e\u0432 \u0434\u043b\u044f Kubernetes \u2014 Helm. \u0412 \u044d\u0442\u043e\u0442 \u0434\u0435\u043d\u044c \u0431\u044b\u043b \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d \u043f\u0435\u0440\u0432\u044b\u0439 \u0430\u043b\u044c\u0444\u0430-\u0440\u0435\u043b\u0438\u0437 \u0431\u0443\u0434\u0443\u0449\u0435\u0439 \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u2014 3.0. \u0415\u0451 \u0432\u044b\u0445\u043e\u0434 \u043f\u0440\u0438\u043d\u0435\u0441\u0451\u0442 \u0432 Helm \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0435 \u0438 \u0434\u043e\u043b\u0433\u043e\u0436\u0434\u0430\u043d\u043d\u044b\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043d\u043e\u0433\u0438\u0435 \u0432 Kubernetes-\u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u0435 \u0432\u043e\u0437\u043b\u0430\u0433\u0430\u044e\u0442 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u043d\u0430\u0434\u0435\u0436\u0434\u044b. \u041a \u0442\u0430\u043a\u043e\u0432\u044b\u043c \u043e\u0442\u043d\u043e\u0441\u0438\u043c\u0441\u044f \u0438 \u043c\u044b \u0441\u0430\u043c\u0438, \u043f\u043e\u0441\u043a\u043e\u043b\u044c\u043a\u0443 \u0430\u043a\u0442\u0438\u0432\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26173,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34735","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\/znakomstvo-s-helm-3\" \/>\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\u0417\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 Helm 3 | 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\/znakomstvo-s-helm-3\" \/>\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=\"2019-10-31T19:00:06+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:00:06+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\udd47 Introduction to Helm 3 | ProHoster","description":"Example.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/znakomstvo-s-helm-3","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\u0417\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 Helm 3 | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/znakomstvo-s-helm-3","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":"2019-10-31T19:00:06+00:00","article:modified_time":"2019-10-31T19:00:06+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34735","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":"2026-01-21 20:26:53","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 23:08:04","updated":"2026-01-21 20:26:53","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\/34735","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=34735"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/34735\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/26173"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=34735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=34735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=34735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}